Subject: #209, was: [new issue] p1 messaging 4.2. fails to account for requested scheme which impacts http compared to https

From: Julian Reschke <[email-masked]>
Date: Sat, 07 Jan 2012 16:56:30 +0100

On 2010-05-20 16:15, Julian Reschke wrote:
> On 19.05.2010 21:55, Henrik Nordström wrote:
>> should we cover this gap?
>>
>> Probably should include something about the port which the request was
>> received on here, as is done by most known server implementations.
>
> Yes. This is a bug.
>
> It's *related* to issue 196 which defines the Effective Request URI
> (where the proposal already takes http vs https into account). Of course
> the "identified/addressed resource" and the "effective request URI"
> definitions need to be consistent.
>
> Now ticket 209 (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/209>)
>
> Best regards, Julian

I just checked the specs, and I think we are almost done with it.

The introduction for PUT now talks about the target resource:

"The PUT method requests that the state of the target resource be 
created or replaced with the state defined by the representation 
enclosed in the request message payload...." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#PUT>

The text from part 1 now says:

"The exact resource identified by an Internet request is determined by 
examining both the request-target and the Host header field." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-18.html#the.resource.identified.by.a.request>

This misses the bit about http vs https, something we get right in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-18.html#effective.request.uri>:

"...the URI needs to be inferred from the request-target, Host header 
field, and connection context. . The result of this process is called 
the "effective request URI". The "target resource" is the resource 
identified by the effective request URI."

It would be nice if we could combine P1 4.2 and 4.3 into a single 
paragraph. However, 4.2 tries to deal with HTTP/1.0 (no Host header 
field), which complicates things a lot :-).

Best regards, Julian