Location header field payload handling

[mnot@…]

The definition of the Location header differs in various ways of how at least Web browsers need to deal with them to interoperate with content on the Web:

1. Need to handle relative URIs.
2. Need to handle with spaces and other invalid URI characters in the same way as done by e.g. HTML and CSS. (Percent-encode them rather than treat it as error.)

I suspect that any other tool that wants to deal with content on the Web would have similar issues. There's some discussion here including two sites this effects:

​http://krijnhoetmer.nl/irc-logs/whatwg/20090323#l-152

[mnot@…]

Proposal:

1) allow relative URIs, base is request-URI only 2) syntax is URI, error handling is application-specific

[julian.reschke@…]

See test cases: ​http://greenbytes.de/tech/tc2231/redirects.html

[julian.reschke@…]

From [785]:

Allow URI-reference instead of URI in Location; state that there are currently no defined precedence rules for fragment identifiers (relates to #43 and #185)

[mnot@…]

Blocked pending some level of liaison with IRIbis.

[mnot@…]

#186 (error handling) may have impact.

[julian.reschke@…]

From [1496]:

Note that some recipients are lax in processing the Location header field (see #185)