- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 26 Apr 2010 12:57:24 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, =JeffH <Jeff.Hodges@KingsMountain.com>
On 23.04.2010 03:46, Mark Nottingham wrote: > > 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." Sounds good to me. >> 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. So do we need to state that? >> 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. OK, so we'll stay silent on this for now. >> 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. 4.2 currently says: "Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested." So it appears we need to cover this case as well. >> 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? I'll have to check :-) Best regards, Julian
Received on Monday, 26 April 2010 10:58:02 UTC