Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support of relative "Location: " for redirect headers #109

Closed
vaab opened this issue Sep 19, 2011 · 3 comments
Closed

support of relative "Location: " for redirect headers #109

vaab opened this issue Sep 19, 2011 · 3 comments

Comments

@vaab
Copy link

vaab commented Sep 19, 2011

Werkzeug ensures that "Location:" header is absolute:

https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/wrappers.py#L958

But why not offer the option to keep it relative. Even if this is not HTTP compliant, it seems supported by all the browser out there. And it allows HTTPS proxying (for example) which current implementation fails to support when using utils.redirect() for example.

This discussion started here (about openerp-web new implementation that uses werkzeug in place of CherryPy):

https://code.launchpad.net/~vaab/openerp-web/proxy-mode-option/+merge/75972

A fix for HTTPS proxying (keeping absolute URL in Location) is also proposed in: #106

What are your thoughts on this topic ?

@vaab
Copy link
Author

vaab commented Sep 21, 2011

The fix mentionned at the end of the commit has been merged in master.

Previous questions remains to be answered.

@mitsuhiko
Copy link
Contributor

This is now possible with 0.8 by overriding an attribute on the response.

@vaab
Copy link
Author

vaab commented Sep 22, 2011

I'm completing your answer which is a little bit short.

A "autocorrect_location_header" attribute is now available in the BaseResponse object can be set to False to avoid enforcing RFC and allow non-absolute "Location: "

Thanks a lot.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants