Re: pylons.decorators.secure.https throws away the query string ?
On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: pylons.decorators.secure.https throws away the query string ?
PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Looking at news, this is only in trunk: http://svn.pythonpaste.org/Paste/Deploy/trunk/docs/news.txt Try: easy_install PasteDeploy==dev Tycon wrote: PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload -- Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
there is another bug in that prefix middleware in that it's trying to strip out the SCRIPT_NAME prefix, which is wrong because that should already be stripped out by the webserver before forwarding the request (at least apache mod_proxy does). In general anything under a Location or Alias directive means that it should never be aware of which location it is in, so the location can be easily changed by the web-server configuration. The reason for SCRIPT_NAME is to allow the application to create links to its own pages absolute URLs (e.g starting with /). not to mention that it's faster to do the prefix stripping in the web server. So right now that middleware will do a second stripping of the SCRIPT_NAME prefix in addition to the stripping by apache, which will cause problems for URLs like /app/app/action On Jan 5, 11:14 am, Ian Bicking i...@colorstudy.com wrote: Looking at news, this is only in trunk:http://svn.pythonpaste.org/Paste/Deploy/trunk/docs/news.txt Try: easy_install PasteDeploy==dev Tycon wrote: PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload -- Ian Bicking : i...@colorstudy.com :http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
One more note regarding nginx reverse proxy setup with a prefix - by
default nginx doesn't seem to strip the prefix when forwarding the
request (unlike apache which does), so you will also need to use the
rewrite directive in nginx to do that, for example:
location /prefix/ {
rewrite ^/prefix(.*) $1 break;
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
proxy_pass http://localhost:5000;
proxy_redirect default;
}
Apache does the right thing by stripping the prefix, as this is the
job of the web server to to map logical URLs.
On Jan 4, 1:03 pm, Tycon adie...@gmail.com wrote:
Here's a new PrefixMiddleware that works correctly:
class PrefixMiddleware(object):
def __init__(self, application, config):
self.application = application
if 'url_prefix' in config:
self.prefix = config['url_prefix'].rstrip('/')
def __call__(self, environ, start_response):
environ['wsgi.url_scheme'] = environ.get
('HTTP_X_FORWARDED_PROTO', 'http')
if 'HTTP_X_FORWARDED_HOST' in environ:
environ['HTTP_HOST']=environ['HTTP_X_FORWARDED_HOST']
if self.prefix:
environ['SCRIPT_NAME']=self.prefix
return self.application(environ, start_response)
It depends on url_prefix setting in the config file (if using a
prefix), and on HTTP_X_FORWARDED_PROTO and HTTP_X_FORWARDED_HOST
headers in the http request to indicate the original host and
protocol.
In apache, HTTP_X_FORWARDED_HOST is set by default (when request is
forwarded using mod_proxy) and you can set the other one like this:
RequestHeader set X_URL_SCHEME https
In nginx, you set them like this:
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
You can use the PrefixMiddleware at the end of config/middleware.py:
app = PrefixMiddleware(app, config)
return app
On Jan 3, 12:34 am, Tycon adie...@gmail.com wrote:
but the PrefixMiddleWare also doesn't seem to be setting the WSGI
environment url_scheme
(nor request.scheme). The PrefixMiddleware code never looks up
HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi
environment. So that needs to be fixed, as well as made clear to
users that they should include it (after it's fixed) if they use a
reverse proxy even without a prefix.
On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote:
On Jan 2, 2009, at 9:45 PM, Tycon wrote:
I submitted a ticket (#554) for this bug, with a proposed fix.
But there is another bug underlying this function which affects
detection of the request's url scheme. This decorator uses
request.scheme to find out if the request was http or https, but in
a reverse proxy configuration this is always set to http even if the
original request was https.
That's not a bug. In a reverse proxy you should be using the
PrefixMiddleware which fixes up the WSGI environ based on headers that
your proxy should set, like X_FORWARDED_FOR, etc.
The routes module (which provides url_for and redirect_to) actually
has a better way of checking the request scheme by using the
HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified
URLs even in proxy mode).
This will likely be removed in favor of using middleware as
appropriate to fix the environ settings based on the deployment
environment.
Cheers,
Ben
smime.p7s
3KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Here's a new PrefixMiddleware that works correctly:
class PrefixMiddleware(object):
def __init__(self, application, config):
self.application = application
if 'url_prefix' in config:
self.prefix = config['url_prefix'].rstrip('/')
def __call__(self, environ, start_response):
environ['wsgi.url_scheme'] = environ.get
('HTTP_X_FORWARDED_PROTO', 'http')
if 'HTTP_X_FORWARDED_HOST' in environ:
environ['HTTP_HOST']=environ['HTTP_X_FORWARDED_HOST']
if self.prefix:
environ['SCRIPT_NAME']=self.prefix
return self.application(environ, start_response)
It depends on url_prefix setting in the config file (if using a
prefix), and on HTTP_X_FORWARDED_PROTO and HTTP_X_FORWARDED_HOST
headers in the http request to indicate the original host and
protocol.
In apache, HTTP_X_FORWARDED_HOST is set by default (when request is
forwarded using mod_proxy) and you can set the other one like this:
RequestHeader set X_URL_SCHEME https
In nginx, you set them like this:
proxy_set_header X_FORWARDED_PROTO $scheme;
proxy_set_header X_FORWARDED_HOST $server_name;
You can use the PrefixMiddleware at the end of config/middleware.py:
app = PrefixMiddleware(app, config)
return app
On Jan 3, 12:34 am, Tycon adie...@gmail.com wrote:
but the PrefixMiddleWare also doesn't seem to be setting the WSGI
environment url_scheme
(nor request.scheme). The PrefixMiddleware code never looks up
HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi
environment. So that needs to be fixed, as well as made clear to
users that they should include it (after it's fixed) if they use a
reverse proxy even without a prefix.
On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote:
On Jan 2, 2009, at 9:45 PM, Tycon wrote:
I submitted a ticket (#554) for this bug, with a proposed fix.
But there is another bug underlying this function which affects
detection of the request's url scheme. This decorator uses
request.scheme to find out if the request was http or https, but in
a reverse proxy configuration this is always set to http even if the
original request was https.
That's not a bug. In a reverse proxy you should be using the
PrefixMiddleware which fixes up the WSGI environ based on headers that
your proxy should set, like X_FORWARDED_FOR, etc.
The routes module (which provides url_for and redirect_to) actually
has a better way of checking the request scheme by using the
HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified
URLs even in proxy mode).
This will likely be removed in favor of using middleware as
appropriate to fix the environ settings based on the deployment
environment.
Cheers,
Ben
smime.p7s
3KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. On Jan 2, 11:32 pm, Ben Bangert b...@groovie.org wrote: On Jan 2, 2009, at 9:45 PM, Tycon wrote: I submitted a ticket (#554) for this bug, with a proposed fix. But there is another bug underlying this function which affects detection of the request's url scheme. This decorator uses request.scheme to find out if the request was http or https, but in a reverse proxy configuration this is always set to http even if the original request was https. That's not a bug. In a reverse proxy you should be using the PrefixMiddleware which fixes up the WSGI environ based on headers that your proxy should set, like X_FORWARDED_FOR, etc. The routes module (which provides url_for and redirect_to) actually has a better way of checking the request scheme by using the HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified URLs even in proxy mode). This will likely be removed in favor of using middleware as appropriate to fix the environ settings based on the deployment environment. Cheers, Ben smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
We do lots of HTTPS with Pylons, we just don't use that decorator. In our case, HTTP - HTTPS redirects are done at the web server layer and not in the application at all. On Fri, Jan 2, 2009 at 3:21 PM, Tycon adie...@gmail.com wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps On Jan 1, 6:23 pm, Tycon adie...@gmail.com wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
that would only work if the web server can determine if a particular request should be http or https, which it could do only if there was something in the request URI to indicate that (like the URI begnning with /secure for example). But what if I have an arbitrary URI (e.g. /hello/login) that should redirect to https, but others (e.g. /hello/logout) that should not ? On Jan 2, 3:29 pm, Bob Ippolito b...@redivi.com wrote: We do lots of HTTPS with Pylons, we just don't use that decorator. In our case, HTTP - HTTPS redirects are done at the web server layer and not in the application at all. On Fri, Jan 2, 2009 at 3:21 PM, Tycon adie...@gmail.com wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps On Jan 1, 6:23 pm, Tycon adie...@gmail.com wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Tycon wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you already know that and the provocative innuendo is just a (quite un-original) technique to prompt a quick response. Anyway, a can think of a few causes for the lack of answers so far: 1) No one is using that decorator. 2) Someone is using but not in an action requiring query string parameters. 3) People are achieving the same effect with different techniques 4) People in a position to fix have aren't reading this 'cause they've taken some days off given that new-years' has been on a Thursday (eg: myself. However, my life's so sad that I'm at home on a Friday night, with my girlfirend, my cat, my Citadelle gin tonic, and my laptop; with obviously nothing better to do than feed some random internet troll) 5) People in a position to fix this are out of patience and have decided to ignore your posts. #1 I doubt since people don't usually submit code for the sake of it. #3 wouldn't be a surprise since the Pylons usually targeted to developers who have already a well equipped toolbox around. I'll place my bets on a combination of #3#4 (#3.5?), I believe it's too early for #5 yet, though you're approaching it a good speed... Now seriously. You've found a bug, congratulations and thanks That's already 2 in less than a week which is quire remarkable and it's certainly preferable an out-of-tone bug report than none at all. However, I think you'd be more positively considered around here if instead of bitching around you'd showed at least a little appreciation for the software you're using for free to build a serious e-commerce website which will probably bring you some revenue. Bonus points if you submit a patch for the bug you've found (you've already proved that you're perfectly capable of doing so) through the conventional channels (the bug tracker is usually the best place) and a unit-test for it if you feel extra-generous. Thanks, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Tycon wrote:
that would only work if the web server can determine if a particular
request should be http or https, which it could do only if there was
something in the request URI to indicate that (like the URI begnning
with /secure for example).
But what if I have an arbitrary URI (e.g. /hello/login) that should
redirect to https, but others (e.g. /hello/logout) that should not ?
Regexps are fun! With nginx:
server {
rewrite ^(.*/login) https://example.com$1 permanent;
}
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
On Jan 1, 2009, at 6:23 PM, Tycon wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. I'm surprised nobody's noticed this bug yet, thanks for pointing it out. We'll get it fixed for 0.9.7 final, though you should log a ticket for it anyway, as we're really good at forgetting about bugs that aren't. A patch would be great -- there is an @https test also, which obviously also needs attention. -- Philip Jenvey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
I submitted a ticket (#554) for this bug, with a proposed fix. But there is another bug underlying this function which affects detection of the request's url scheme. This decorator uses request.scheme to find out if the request was http or https, but in a reverse proxy configuration this is always set to http even if the original request was https. The routes module (which provides url_for and redirect_to) actually has a better way of checking the request scheme by using the HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified URLs even in proxy mode). Anyway, that is a separate issue that needs to be fixed in the middleware that sets the request.scheme and the environ ['wsgi.url_scheme'], because they should reflect the original request's scheme regardless if the app is served via proxying or embedding. On Jan 2, 7:26 pm, Philip Jenvey pjen...@underboss.org wrote: On Jan 1, 2009, at 6:23 PM, Tycon wrote: This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. I'm surprised nobody's noticed this bug yet, thanks for pointing it out. We'll get it fixed for 0.9.7 final, though you should log a ticket for it anyway, as we're really good at forgetting about bugs that aren't. A patch would be great -- there is an @https test also, which obviously also needs attention. -- Philip Jenvey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you Which of those sites do you consider hip and/or serious ? On Jan 2, 4:26 pm, Alberto Valverde albe...@toscat.net wrote: Tycon wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you already know that and the provocative innuendo is just a (quite un-original) technique to prompt a quick response. Anyway, a can think of a few causes for the lack of answers so far: 1) No one is using that decorator. 2) Someone is using but not in an action requiring query string parameters. 3) People are achieving the same effect with different techniques 4) People in a position to fix have aren't reading this 'cause they've taken some days off given that new-years' has been on a Thursday (eg: myself. However, my life's so sad that I'm at home on a Friday night, with my girlfirend, my cat, my Citadelle gin tonic, and my laptop; with obviously nothing better to do than feed some random internet troll) 5) People in a position to fix this are out of patience and have decided to ignore your posts. #1 I doubt since people don't usually submit code for the sake of it. #3 wouldn't be a surprise since the Pylons usually targeted to developers who have already a well equipped toolbox around. I'll place my bets on a combination of #3#4 (#3.5?), I believe it's too early for #5 yet, though you're approaching it a good speed... Now seriously. You've found a bug, congratulations and thanks That's already 2 in less than a week which is quire remarkable and it's certainly preferable an out-of-tone bug report than none at all. However, I think you'd be more positively considered around here if instead of bitching around you'd showed at least a little appreciation for the software you're using for free to build a serious e-commerce website which will probably bring you some revenue. Bonus points if you submit a patch for the bug you've found (you've already proved that you're perfectly capable of doing so) through the conventional channels (the bug tracker is usually the best place) and a unit-test for it if you feel extra-generous. Thanks, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
On Jan 2, 2009, at 9:45 PM, Tycon wrote: I submitted a ticket (#554) for this bug, with a proposed fix. But there is another bug underlying this function which affects detection of the request's url scheme. This decorator uses request.scheme to find out if the request was http or https, but in a reverse proxy configuration this is always set to http even if the original request was https. That's not a bug. In a reverse proxy you should be using the PrefixMiddleware which fixes up the WSGI environ based on headers that your proxy should set, like X_FORWARDED_FOR, etc. The routes module (which provides url_for and redirect_to) actually has a better way of checking the request scheme by using the HTTP_X_FORWARDED_PROTO header (so it correctly creates fully qualified URLs even in proxy mode). This will likely be removed in favor of using middleware as appropriate to fix the environ settings based on the deployment environment. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
pylons.decorators.secure.https throws away the query string ?
This decorator is supposed to redirect HTTP GET requests to HTTPS. But guess what ? The query string in the request URI is lost, so the redirected (https) request will not have any request.params even if the original (http) request did. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
