W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Issue 196, was: #110: how to determine what entity a response carries

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 23 Apr 2010 11:46:47 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, =JeffH <Jeff.Hodges@KingsMountain.com>
Message-Id: <D7F73724-4420-4001-ADF8-DB80D449858B@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 23/04/2010, at 12:55 AM, Julian Reschke wrote:
> For now I have added this to the proposed patch (which is work-in-progress), see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/196/i196.3.diff>; the definition now reads:
> - snip -
> 4.3.  Effective Request URI
>   The term "Effective Request URI" is introduced in order to abstract
>   away the various syntactical forms a request can take.

Suggested introduction:

HTTP requests often do not carry the absolute-URI [ref to 3986] for they are intended; instead, the value needs to be inferred from the request-target, Host header and other context. The result of this process is the "Effective Request URI."

>   If the request-target is an absolute-URI, then the Effective Request
>   URI is the request-target. [[effrequri-scheme: What about the case
>   where the given scheme name and the transport disagree?  What if
>   actual and specified port disagree? --jre]]

It's perfectly acceptable to send a request for http://foo.com to a proxy via HTTPS on a different port. I think this is a separate problem; what happens when a server gets an effective request URI that they don't / can't / won't handle, and how much error correction do they attempt? I think both are implementation-specific.

>   If the request-target uses the path-absolute (plus optional query)
>   syntax or if it is just the asterisk "*", then the Effective Request
>   URI is constructed by concatenating
>   o  the scheme name: "http" if the request was received over an
>      insecure TCP connection, or "https" when received over SSL/
>      TLS-secured TCP connection, [[effrequri-othertransports: Need to
>      mention other future transports here? --jre]]

I think that's their problem; they can update this RFC.

>   o  the character sequence "://",
>   o  the authority component, as specified in the Host header
>      (Section 9.4) and determined by the rules in Section 4.2,
>      [[effrequri-nohost: How do we deal with undefined hosts? --jre]]
>      and

p1 2.6.1 already has

> http-URI = "http:" "//" authority path-abempty [ "?" query ]

> The host MUST NOT be empty; if an "http" URI is received with an empty host, then it MUST be rejected as invalid.

>   o  the request-target obtained from the Request-Line, unless the
>      request-target is just the asterisk "*".
>   Otherwise, when request-target uses the authority form, the Effective
>   Request URI is undefined.
>   Example 1: the Effective Request URI for the message
>     GET /pub/WWW/TheProject.html HTTP/1.1
>     Host: www.example.org:8080
>   (received over an insecure TCP connection) is "http", plus "://",
>   plus the authority component "www.example.org:8080", plus the
>   request-target "/pub/WWW/TheProject.html", thus
>   "http://www.example.org:8080/pub/WWW/TheProject.html".
>   Example 2: the Effective Request URI for the message
>     GET * HTTP/1.1
>     Host: www.example.org
>   (received over an SSL/TLS secured TCP connection) is "https", plus
>   "://", plus the authority component "www.example.org", thus
>   "https://www.example.org".
>      [[eru-options: Need to point out that we are not defining an URI
>      for OPTIONS * here. --jre]]
>   [[effrequri-compare: Need to declare comparison?  Can we re-use the
>   comparison defined in Section 2.6.3? --jre]]

I'd hope so... any reason why not?


Mark Nottingham     http://www.mnot.net/
Received on Friday, 23 April 2010 01:47:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC