support relative URI references in Location header in Agent
|Reported by:||glyph||Owned by:||amberite|
While discussing the ticket about putting getPage on top of Agent with amberite, it came to light that one blocking issue was the differing behavior of getPage and Agent with respect to relative URI references in the Location header on redirects. While the ticket doesn't contain this discussion (hey, update the ticket next time, jerks), amberite summarized as follows: getPage does kinda what browsers do and follows relative redirects, but Agent is more spec-ly correct and instead generates an error, so replacing the implementation of getPage with one based on Agent might constitute an incompatible change.
Except, browsers are pretty popular HTTP clients, so we should probably emulate their behavior more often than not. However, this distinction is fast becoming irrelevant anyway, since the spec is evolving to come into line with what browsers do. Handily, this means we have a formal statement of what exactly a relative URI should do, rather than just some random observations of browser behavior to guess based on. As the HTTPbis semantics draft 18 puts it:
When ![the Location header] has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).
In other words, what URLPath.click does. (URLPath.click's exact adherence to RFC 3986 section 5 is a topic for a different ticket.)
Change History (5)
comment:2 Changed 4 years ago by exarkun
- Resolution set to duplicate
- Status changed from new to closed
comment:3 Changed 2 years ago by jonathanj
- Keywords agent added
- Resolution duplicate deleted
- Status changed from closed to reopened