Opened 3 years ago

Closed 19 months 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:
Author: Launchpad Bug:

Description

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:1 Changed 3 years ago by DefaultCC Plugin

  • Cc jknight added

comment:2 Changed 3 years ago by exarkun

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #5434.

comment:3 Changed 21 months ago by jonathanj

  • Keywords agent added
  • Resolution duplicate deleted
  • Status changed from closed to reopened

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 21 months ago by jonathanj

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

comment:5 Changed 19 months ago by jonathanj

  • Resolution set to fixed
  • Status changed from reopened to closed

(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.