Community
Participate
Working Groups
Build Identifier: According to the docs[1], if you has Apache terminating an SSL connection and proxying requests to Jetty, then to pass the original URL scheme, and perhaps other data, you must write a custom extended connector. That seems like a kind of high bar for something that I would have thought was a decently common setup. I'd like to propose something to make this scenario a bit simpler. For each connection property (e.g., scheme, connection confidentiality) that is masked by the proxy I would recommend the following: - add a configuration field, with corresponding getters/setters to the Connector (probably org.eclipse.jetty.server.AbstractConnector) - in the Connector#customize(Endpoint, Request) method, if the previously mentioned options are set, then set them on the request. Otherwise, don't. This would be a backwards compatible addition but would also make dealing with the Apache-terminated SSL case, and perhaps others, much simpler to deal with. If this seems reasonable I'll write up a patch for it. [1] http://docs.codehaus.org/display/JETTY/Configuring+mod_proxy Reproducible: Always
Created attachment 186121 [details] Minimally invasive patch that allows setting scheme and secure'ness of proxied connection Attached is a jetty-server patch that tries to be very non-invasive and allow for overriding the scheme and secure'ness properties of the request.
Created attachment 186122 [details] Disregard patch 1, forgot to save a file.
Comment on attachment 186121 [details] Minimally invasive patch that allows setting scheme and secure'ness of proxied connection marking attachment as obsolete according to submitter comments
Gunnar & Chad, Jetty-7 now handles the quasi standard X-Forwarded-Proto header, so if you can add that from apache and set it to https, then jetty will set the scheme and confidentiality accordingly. is that sufficient?
Sure, that sounds good to me. I'll try to get some verbiage in to the Jetty wiki, some time this week, to note this as well.
