Opened 10 years ago

Closed 9 years ago

#5462 enhancement closed fixed (fixed)

support relative URI references in Location header in Agent

Reported by: Glyph Owned by: amberite
Priority: normal Milestone:
Component: web Keywords: agent
Cc: jknight Branch:


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 does. ('s exact adherence to RFC 3986 section 5 is a topic for a different ticket.)

Change History (5)

comment:1 Changed 10 years ago by DefaultCC Plugin

Cc: jknight added

comment:2 Changed 10 years ago by Jean-Paul Calderone

Resolution: duplicate
Status: newclosed

Duplicate of #5434.

comment:3 Changed 9 years ago by Jonathan Jacobs

Keywords: agent added
Resolution: duplicate
Status: closedreopened

As mentioned in the original description, according to the latest HTTP 1.1 bis draft relative location URIs are allowed behaviour. This ticket was previously marked as a duplicate of a ticket proposing a new redirect agent that behaved like a browser.

I'm re-opening this ticket because relative location URIs should be considered good behaviour and not only browser-like.

comment:4 Changed 9 years ago by Jonathan Jacobs

(In [37885]) Resolve relative URIs in RedirectAgent and BrowserLikeRedirectAgent, refs #5434, #5462.

comment:5 Changed 9 years ago by Jonathan Jacobs

Resolution: fixed
Status: reopenedclosed

(In [38672]) Merge browser-like-redirect-agent-5434-2.

Author: jonathanj Reviewer: tom.prince, rwall Fixes: #5434, #5462

Introduce BrowserLikeRedirectAgent, a RedirectAgent subclass, that handles redirects more like a web browser, specifically it treats HTTP 301 and 302 like HTTP 303 on non-HEAD/GET requests and changes the method to GET before proceeding.

RedirectAgent now also resolves relative URI references in the Location header against the most recent request URI.

Note: See TracTickets for help on using tickets.