Skip to content

Relative location headers are "fixed" as if they are relative to root instead of the current url #693

Description

@boblehest

https://github.com/mitsuhiko/werkzeug/blob/542b2e95d4e39ed8f0ec186b88eb20ff70544168/werkzeug/wrappers.py#L1129

When the location header points to a relative address, werkzeug grabs the root of the url, which for example.com/a/b/c/d/e turns into example.com, and then adds the relative location on top, which doesn't turn out well.

Why not use the full url when correcting it? In my case if I get redirected from example.com/path/to/file to ../abc, I'd want to end up at example.com/path/abc instead of example.com/abc.

Activity

  1. untitaker commented on Mar 22, 2015

    @untitaker
    Contributor

    The location header can't be relative, as per RFC 2616:

    The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.

  2. untitaker commented on Mar 22, 2015

    @untitaker
    Contributor

    I'd accept patches that change the behavior (since it'd still be RFC-compliant, just more tolerant) as long as there are no performance penalties.

  3. boblehest commented on Mar 26, 2015

    @boblehest
    ContributorAuthor

    Edit: PR #718

    Edit: Aww, github deleted my entire comment when I clicked "edit", what a cool feature. Quick rehash: As you can see in the PR, it appears (to me) to be a really simple fix, unless there's something I'm missing.

  4. untitaker commented on Apr 4, 2015

    @untitaker
    Contributor

    Your original comment I recieved via mail:

    Yeah, I know it can't be relative. I've set up a proxy server for an internal http server, and unfortunately it doesn't honor the spec.

    The problem is that I think the corrected location should be relative to the "working directory", which it currently isn't.

    The fix appears to be really simple, unless I'm missing something (for the record, this is nowhere near my area of expertise).

    PR coming up.

  5. mjpieters commented on Oct 13, 2016

    @mjpieters

    RFC 7231 changed the Location requirements, see section 7.1.2:

    The field value consists of a single URI-reference. When it 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).

    As such, the location header does not have to be absolute anymore. Werkzeug may choose to remain conservative in this (and require you to set BaseResponse.autocorrect_location_header to False explicitly).

  6. added this to the 0.15 milestone on May 28, 2018
  7. davidism commented on May 28, 2018

    @davidism
    Member

    For reference, even after the PR, the header will still end up with an absolute path, it's just that relative paths will be relative to the current path instead of the root path. If you actually want a relative URL in the header, disable autocorrect_location_header.

  8. meghabh commented on Dec 3, 2019

    @meghabh

    How can I still use the root url, instead of current path . Is it by setting up autocorrect_location_header to flase ?

  9. locked as resolved and limited conversation to collaborators on Nov 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions