- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 22 Apr 2010 16:55:02 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>, =JeffH <Jeff.Hodges@KingsMountain.com>
On 14.04.2010 17:17, Julian Reschke wrote:
> On 13.04.2010 16:41, Julian Reschke wrote:
>> ...
>> Here's proposed text for the definition of "Effective Request URI", with
>> questions inlined:
>> ...
>
> I did some more work, and started to consider how this effects Part 2
> (see
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/196/i196.2.diff>).
>
>
> As expected, it works well for "Identifying the Resource Associated with
> a Representation"
> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-09.html#rfc.section.6.1>).
>
>
> However, in general it's not as easy as simply replacing
> "request-target" by "Effective Request URI".
>
> The reason for this is that with the currently proposed definition,
> "Effective Request Target" is undefined for certain requests, such as
> when request-target is "*" or just an authority component.
>
> Should we re-consider this, mapping the request
>
> OPTIONS * HTTP/1.1
> Host: example.org
>
> to the Effective Request URI
>
> http://example.org
>
> (note no trailing slash)?
> ...
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.
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]]
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]]
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
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]]
- snip -
Best regards, Julian
Received on Thursday, 22 April 2010 14:55:44 UTC