Re: [whatwg] WF2 - <form action="">

Geoff Richards schreef:
> On Thu, Jan 17, 2008 at 01:03:45PM -0600, Boris Zbarsky wrote:
>   
>> ...
>>
>> Also note that RFC 3986 obsoletes RFC 2396 and changes these rules 
>> somewhat. Which one are we normatively referencing here?  Or should we be 
>> referencing RFC 1808?  The situation is not all that clear-cut.
>>     
>
> We should be referencing the most recent URI standard, RFC 3986.
> According to that, a relative URI which is empty or just contains a
> fragment part should resolve to the base URI, except with the original
> fragment part (if any) removed, and the new one (if any) added.  So, if
> the document URI or base URI in scope on the 'form' element is
> 'http://a/b/c/d;p?q#f' then resolving should give these results:
>
>     "" -> "http://a/b/c/d;p?q"
>     "#newfrag" -> "http://a/b/c/d;p?q#newfrag"

Ah, sorry, I didn’t realise that RFC 2396 was superseded. I guess I need 
to update my implementation [1] then! :)

But anyway, please see the overview of modifications in section D.2. 
[2], the third bullet point for the explanation of the changes between 
the two specifications in this regard:

> The determination of whether a URI reference is a same-document 
> reference has been decoupled from the URI parser, simplifying the URI 
> processing interface within applications in a way consistent with the 
> internal architecture of deployed URI processing implementations. The 
> determination is now based on comparison to the base URI after 
> transforming a reference to absolute form, rather than on the format 
> of the reference itself. This change may result in more references 
> being considered "same-document" under this specification than there 
> would be under the rules given in RFC 2396 
> <http://www.apps.ietf.org/rfc/rfc2396.html>, especially when 
> normalization is used to reduce aliases. However, it does not change 
> the status of existing same-document references. 

In other words, the concept of same-document references being an 
exception still remains, however it has been reformulated. Note that in 
the last line, it basically says that what was a same-document reference 
in RFC 2396, is still a same-document reference in this newer RFC, so 
nothing really changed for them.

To be specific, the section that applies here now is section 4.4 [3], quote:

> When a URI reference refers to a URI that is, aside from its fragment 
> component (if any), identical to the base URI (Section 5.1 
> <http://www.apps.ietf.org/rfc/rfc3986.html#sec-5.1>), that reference 
> is called a "same-document" reference. The most frequent examples of 
> same-document references are relative references that are empty or 
> include only the number sign ("#") separator followed by a fragment 
> identifier.
>
> When a same-document reference is dereferenced for a retrieval action, 
> the target of that reference is defined to be within the same entity 
> (representation, document, or message) as the reference; therefore, a 
> dereference should not result in a new retrieval action.
>

So, when resolving these two URIs:

    "" -> "http://a/b/c/d;p?q"
    "#newfrag" -> "http://a/b/c/d;p?q#newfrag"


These are indeed the resolved URIs. However, when dereferencing them, it 
is still a same-document reference, because the base URI is identical to 
the resolved URI (minus the fragment).

Although I must admit the specification only talks about retrieval 
actions (i.e. a GET) and not about what should happen when using POST. 
Clearly it should send a request then, but whether that is to the base 
URI or the current document URI is not entirely clear to me. 
Additionally, for a form that uses the GET method, after putting the 
query string in the action URI, it is likely no longer a same-document 
reference because the URI has changed.

Fortunately, the older RFC2396 is much more clear in this regard, quote:

> However, if the URI reference occurs in a context that is always 
> intended to result in a new request, as in the case of HTML's FORM 
> element, then an empty URI reference represents the base URI of the 
> current document and should be replaced by that URI when transformed 
> into a request.

So although for a regular anchor link it is pretty clear what should 
happen, in the case of a form submission it is less so, and actually, 
after considering this, it’s probably correct to say that the submission 
should indeed be done to the URI that is resolved against the base URI, 
even though the latest version of the URI RFC does not explicitly say so 
anymore (an unintentional omission, I assume?).

I think it’s safe to say that as a ground rule, all actual requests 
should be done relative to the base URI. However, when it is a 
same-document reference, provided no communication with the server is 
necessary (as is the case for GET requests which are ‘safe’), the 
existing document can be re-used. The latter is what happens when you 
click on a link, and also what happens in e.g. XSLT or XInclude.

So there is one more ‘but’: one could argue that if the final URI for a 
GET submission matches the base URI exactly, no submission has to be 
done because that document is already loaded. I’m not sure whether any 
browser currently implements this, nor whether it is sensible.

By the way, please note that the base URI in your earlier example is not 
a valid base URI; base URIs can not contain fragment identifiers, see [4].


~Grauw

[1] http://www.grauw.nl/articles/resolve-uri.html
[2] http://www.apps.ietf.org/rfc/rfc3986.html#sec-D.2
[3] http://www.apps.ietf.org/rfc/rfc3986.html#sec-4.4
[4] http://www.apps.ietf.org/rfc/rfc3986.html#sec-4.3

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.