Shannon -jj Behrens wrote: > On 4/6/07, Ian Bicking <[EMAIL PROTECTED]> wrote: >> Does anyone know of existing conventions around forwarding HTTP >> connections? There's X-Forwarded-For (REMOTE_ADDR), the less-used >> X-Forwarded-Server (Host). On top of that, I imagine X-Forwarded-Scheme >> makes sense (wsgi.url_scheme), though I haven't seen that used. That >> mostly leaves the idea of script name and path info, and possibly some >> other traversal path (which I don't like, but some systems use). >> >> So, there's kind of three pieces of information: >> * SCRIPT_NAME, how we got here >> * PATH_INFO, what is left to parse >> * Traversal, some indication of what you want the remote server to select >> >> So a typical setup like: >> >> ProxyPass /a http://localhost:8080/b >> >> Means that "/a" is the SCRIPT_NAME, "/b" is the traversal path. If /a/c >> is requested, it's forwarded to /b/c, and "/c" is PATH_INFO. In a sense >> X-Forwarded-Server is a kind of traversal too, as you *could* send the >> original Host header (even if that isn't the hostname you connected to), >> but many servers could be weird about that. So in effect the "real" >> Host header is either effectively garbage ("localhost") or some kind of >> traversal information. But usually it's garbage. >> >> So there's a lot of ways you could communicate this information. >> PrefixMiddleware lets you fix it up when it's wrong through >> configuration, but I'd at least like to have some kind of convention >> that could be used in addition (fixing up the environment, but with a >> middleware that doesn't require any configuration). >> >> There's a few options: >> >> /a/c -> /b/c, X-Forwarded-Script-Name: '/a', X-Forwarded-Path-Info: '/c' >> /a/c -> /b/c, X-Forwarded-Script-Name: '/a', X-Traverse-To: '/c' >> /a/c -> /a/c, X-Forwarded-Script-Name: '/a', X-Traverse-To: '/c' >> (in this option the intermediaries have to understand X-Traverse-To) >> /a/c -> /b/a/c, X-Forwarded-Script-Name: '/a' >> (in this option the application has to figure out itself that /b is a >> traversal, using whatever the native conventions/configurations are) >> >> Obviously not all options are possible. Some are going to be difficult >> with awkward servers like Apache that don't offer many options for >> fixing up the request. I'm not sure, for instance, how much you can >> change the request information in PHP. And I think you *can* change >> this information in Apache, but it might require writing new Apache >> modules, and that's no fun (even using mod_python). Though I'm not sure >> how much the request environment is trusted in Apache; there's ways to >> change it fairly flexibly with mod_rewrite, but only the environment >> dictionary. >> >> Anyway, I'm hoping someone has some opinions, because handling this >> through configuration sucks, so I really want to do something to handle >> this more automatically. > > I think I mentioned before that in Aquarium I *always* did the following: > > If present, use the ``X_FORWARDED_HOST`` header (i.e. > ``cgiEnv["HTTP_X_FORWARDED_HOST"]) in order to override > ``cgiEnv["SERVER_NAME"]`` and ``cgiEnv["SERVER_PORT"]``. > > That way, it works with no configuration. > > I'm sure the situation is a lot more tricky if you have multiple > levels of proxies.
I'm planning on doing this in middleware (not in every URL-accessing function), but it's still an incomplete mapping. (I had vaguely remembered X-Forwarded-Server instead of X-Forwarded-Host?) I'd probably leave SERVER_NAME and SERVER_PORT alone, and only overwrite HTTP_HOST, which should generally take precedence anyway. Though I dunno, PrefixMiddleware overwrites both HTTP_HOST and SERVER_NAME/PORT currently. SERVER_NAME is generally fairly useless anyway, kind of an HTTP/1.0 holdover. > By the way, this is something that was taken care of really well in > SIP, not that that helps us at all ;) Do you know what they used there? I'm interested in how to communicate the path information in particular. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers _______________________________________________ Paste-users mailing list [email protected] http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
