Subject: [http-state] wrt terminology: "request-host" and "request-uri"

From: =JeffH <[email-masked]>
Date: Tue, 14 Sep 2010 13:34:18 -0700

What follows is a long-winded justification for this suggested spec fixup. If 
you want to cut to the chase, jump ahead to "Suggested Fix".

A few of us have noted that the present definitions/explanations of the terms 
"request-host" and "request-uri" in the spec could use clarification.

In fact, when i was working on early versions of the spec that became the HSTS 
spec where I derived the term "effective request URI", I'd been looking at both 
RFC2109 and RFC2616 trying to figure out how to denote the URI being referred 
to by any given HTTP request (i.e. from the "server", or the "passive observer 
of HTTP msgs-on-the-wire" perspectives). And I had come to the conclusion that 
"request-uri" and "request-URI" as used in RFCs 2109/2616 was misleadingly 
named and not what was needed. Thus the invention of "effective request URI" 
(which has been adopted into the HTTPbis specs (in 
draft-ietf-httpbis-p1-messaging).

However, that said, we're trying to get this spec, draft-ietf-httpstate-cookie, 
out the proverbial door ahead of the HTTPbis spec set, /plus/ -httpstate-cookie 
documents current practice, and thus it is appropriate IMV for it to depend on 
the earlier (i.e. "current") HTTP specs RFCs 2616 (and 1945, if appropriate) 
rather than HTTPbis.

Julian had suggested we might cut'n'paste the definition of "effective request 
URI (ERU)" into -httpstate-cookie, and I looked at that but it seemed overkill 
to me, plus Julian has fixed some issues and re-written ERU in the context of 
HTTPbis specs and it just wouldn't work without overhaul.

So it turns out that "request-host" is a term that's defined locally here in 
-httpstate-cookie (and had also been so locally defined in RFC2109), so we can 
just simply define it as it is in terms of being when a message is being sent 
or received from.

"Request-uri" is defined in RFC2616, however it is sorta complicated and isn't 
always a proper URI -- often it's just a path component -- and so mentioning 
"absoluteURI (http_URL)" (as well as "Request-Line") as done in the original 
RFC2109 definition is misleading.

So I think we should just say "request-uri" is defined in RFC2616, and leave it 
at that. One minor nit is that in RFC2616 request-uri is written as 
"Request-URI". We /could/ also "s/request-uri/Request-URI/g" to our spec (not 
strictly necessary tho imv).

Below is first the present Terminology section text, then the suggested fix in 
text and xml, and then some email msgs from prior threads where this issue was 
raised.

HTH,

=JeffH
------

Present text..
(I've included the entire (short) "terminology" section for context)

2.3. Terminology

    The terms user agent, client, server, proxy, and origin server have
    the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
    1.3).

    The terms request-host and request-uri refer to the values the user
    agent would send to the server as, respectively, the host (but not
    port) and the absoluteURI (http_URL) of the HTTP Request-Line.

    Two sequences of octets are said to case-insensitively match each
    other if and only if they are equivalent under the i;ascii-casemap
    collation defined in [RFC4790].

Suggested Fix (text)..

----8<----
2.3. Terminology

    The terms user agent, client, server, proxy, and origin server have
    the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
    1.3).

    Request-host is the fully-qualified domain name of the host to
    which the user agent is sending a HTTP request, or is receiving a
    HTTP response from (in response to such a request).

    Request-uri is defined in Section 5.1.2 of [RFC2616].

    Two sequences of octets are said to case-insensitively match each
    other if and only if they are equivalent under the i;ascii-casemap
    collation defined in [RFC4790].
---->8----

Suggested Fix (xml)..

----8<----
       <section anchor="terminology" title="Terminology">
         <t>The terms user agent, client, server, proxy, and origin server have
         the same meaning as in the HTTP/1.1 specification (<xref
         target="RFC2616" />, Section 1.3).</t>

         <t>Request-host is the fully-qualified domain name of the host to
         which the user agent is sending a HTTP request, or is receiving a
         HTTP response from (in response to such a request).</t>

         <t>Request-uri is defined in Section 5.1.2 of <xref
         target="RFC2616" />.</t>

         <t>Two sequences of octets are said to case-insensitively match each
         other if and only if they are equivalent under the i;ascii-casemap
         collation defined in <xref target="RFC4790"/>.</t>
       </section>
---->8----

applicable messages..

 > Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1
 > 	- 4.1.2.)
 > From: Adam Barth <[email-masked]>
 > Date: Wed, 26 May 2010 13:45:22 -0700
 > To: Bjoern Hoehrmann <[email-masked]>
 > Cc: [email-masked]

 >> In section 2.3 we have "The terms request-host and request-uri refer to
 >> the values the user agent would send to the server as, respectively, the
 >> host (but not port) and the absoluteURI (http_URL) of the HTTP
 >> Request-Line." I am not entirely sure how to read that; for example, the
 >> "host" would be part of "absoluteURI" if it is sent in the Request-Line,
 >> and sending an absoluteURI there is unusual (unless talking to a proxy).
 >> Also, the reference to http_URL is probably incorrect if "https" URLs
 >> are also permissable.
 >
 > I find it completely ridiculous that the specs make it so hard to say
 > what URL and host we're sending a request to, which would seem to be
 > the two most important things about an HTTP request.  Hopefully
 > someone will chime in with the magic incantation we're supposed to use
 > here.

 > Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08.txt (1
 > 	- 4.1.2.)
 > From: Adam Barth <[email-masked]>
 > Date: Sun, 30 May 2010 18:58:23 -0700
 > To: Bjoern Hoehrmann <[email-masked]>
 > Cc: [email-masked]
 >
 > ... <snip/> ...
 >
 >> If you're willing to wait for httpbis, "Effective Request URI" might be the
 >> right thing
 >> 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#effective.request.uri>).
 >
 > I'm glad this is getting fixed.  I don't particularly want to take a
 > dependency on HTTPbis, as discussed before.
 >
 > ... <snip/> ...

 > Subject: [http-state] terminology: "request-host" and "request-uri"
 > From: Julian Reschke <[email-masked]>
 > Date: Fri, 16 Jul 2010 14:48:04 +0200
 > To: "[email-masked]" <[email-masked]>
 >
 > Hi,
 >
 > the spec currently has
 > (<http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-2.3>):
 >
 >     The terms request-host and request-uri refer to the values the user
 >     agent would send to the server as, respectively, the host (but not
 >     port) and the absoluteURI (http_URL) of the HTTP Request-Line.
 >
 > First of all, it would be good if ABNF terms from RFC 2616 would be
 > clearly introduced as such.
 >
 > Such as
 >
 >     This specification adopts the definition of "http_URL" from Section
 >     3.2.2 of [RFC2616].
 >
 > (or something similar) -- this should be done for all terms/ABNF
 > productions used from other spec.
 >
 > Furthermore, there's a problem request-host, which, depending on the
 > format of the HTTP Request-Line will *either* come from the Host header
 > field, or from the Request-Line.
 >
 > In HTTPbis, we have introduced the term "Effective Request URI", see
 > 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-10.html#rfc.section.4.3>, 

 > based on which extracting thee host and the request path would be
 > simpler. If you don't want to rely on that definition due to spec
 > timing, you may want to consider to steal the spec text (originally
 > introduced by Jeff for STS, btw).
 >
 > Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Thu, 16 Sep 2010 01:29:54 -0700

Done:

http://github.com/abarth/http-state/commit/aae9e145b5881c4d153046d4a48e757eaf1fc5e3

I massaged the text slightly.  Generally, I don't like to use defined
terms as the first word in a sentence because that screws up the
capitalization, etc.

Adam

On Tue, Sep 14, 2010 at 1:34 PM, =JeffH <[email-masked]> wrote:
> What follows is a long-winded justification for this suggested spec fixup.
> If you want to cut to the chase, jump ahead to "Suggested Fix".
>
>
> A few of us have noted that the present definitions/explanations of the
> terms "request-host" and "request-uri" in the spec could use clarification.
>
> In fact, when i was working on early versions of the spec that became the
> HSTS spec where I derived the term "effective request URI", I'd been looking
> at both RFC2109 and RFC2616 trying to figure out how to denote the URI being
> referred to by any given HTTP request (i.e. from the "server", or the
> "passive observer of HTTP msgs-on-the-wire" perspectives). And I had come to
> the conclusion that "request-uri" and "request-URI" as used in RFCs
> 2109/2616 was misleadingly named and not what was needed. Thus the invention
> of "effective request URI" (which has been adopted into the HTTPbis specs
> (in draft-ietf-httpbis-p1-messaging).
>
> However, that said, we're trying to get this spec,
> draft-ietf-httpstate-cookie, out the proverbial door ahead of the HTTPbis
> spec set, /plus/ -httpstate-cookie documents current practice, and thus it
> is appropriate IMV for it to depend on the earlier (i.e. "current") HTTP
> specs RFCs 2616 (and 1945, if appropriate) rather than HTTPbis.
>
> Julian had suggested we might cut'n'paste the definition of "effective
> request URI (ERU)" into -httpstate-cookie, and I looked at that but it
> seemed overkill to me, plus Julian has fixed some issues and re-written ERU
> in the context of HTTPbis specs and it just wouldn't work without overhaul.
>
> -httpstate-cookie (and had also been so locally defined in RFC2109), so we
> can just simply define it as it is in terms of being when a message is being
> sent or received from.
>
> "Request-uri" is defined in RFC2616, however it is sorta complicated and
> isn't always a proper URI -- often it's just a path component -- and so
> mentioning "absoluteURI (http_URL)" (as well as "Request-Line") as done in
> the original RFC2109 definition is misleading.
>
> So I think we should just say "request-uri" is defined in RFC2616, and leave
> it at that. One minor nit is that in RFC2616 request-uri is written as
> "Request-URI". We /could/ also "s/request-uri/Request-URI/g" to our spec
> (not strictly necessary tho imv).
>
> Below is first the present Terminology section text, then the suggested fix
> in text and xml, and then some email msgs from prior threads where this
> issue was raised.
>
> HTH,
>
> =JeffH
> ------
>
> Present text..
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>