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

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<>; 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 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:
>>    (received over an insecure TCP connection) is "http", plus "://",
>>    plus the authority component "", plus the
>>    request-target "/pub/WWW/TheProject.html", thus
>>    "".
>>    Example 2: the Effective Request URI for the message
>>      GET * HTTP/1.1
>>      Host:
>>    (received over an SSL/TLS secured TCP connection) is "https", plus
>>    "://", plus the authority component "", thus
>>    "".
>>       [[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