Jetty

Need a defaultScheme property for AbstractConnector

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 6.1.1
  • Fix Version/s: 7.1.0
  • Component/s: HTTP
  • Labels:
    None
  • Environment:
    Linux, JDK 5, Running behind an Apache 2.0.52? server
  • Number of attachments :
    0

Description

We are migrating from Jetty 5 -> 6. We run Jetty behind apache web server - apache reverse proxies to Jetty. When we have SSL connections into apache, they connect to Jetty via a SelectChannelConnector. In Jetty 5 we had a number of org.mortbay.http.SocketListeners. On one (meant to handle the proxied ssl connections) we set defaultScheme to https. This meant that any redirects coming out of Jetty on this listener would default to https redirects.

Any chance for a similar mechanism in Jetty 6?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Greg Wilkins added a comment -

I don't think we will add it in Jetty 6, because it is so simple to do with an anonymous class:

Server server=new Server();
Connector connector=new SocketConnector()
{
public void customize(EndPoint endpoint, Request request) throws IOException

{ super.customize(endpoint,request); request.setScheme("https"); }

};

server.addConnector(connector);
....

If this is not sufficient, please reopen this issue.

cheers

Show
Greg Wilkins added a comment - I don't think we will add it in Jetty 6, because it is so simple to do with an anonymous class: Server server=new Server(); Connector connector=new SocketConnector() { public void customize(EndPoint endpoint, Request request) throws IOException { super.customize(endpoint,request); request.setScheme("https"); } }; server.addConnector(connector); .... If this is not sufficient, please reopen this issue. cheers
Hide
Permalink
Ross Lamont added a comment -

Was planning to do something like this anyway to get us out of the woods, but we are treating Jetty as a package - not calling it from custom code, so we'd have to write our own connector, dump it in the ext directory, remember to copy the jar when we upgrade jetty etc etc.

I'd prefer it be reopened, but I don't have the permission to do so.

Happy to submit a patch...

Show
Ross Lamont added a comment - Was planning to do something like this anyway to get us out of the woods, but we are treating Jetty as a package - not calling it from custom code, so we'd have to write our own connector, dump it in the ext directory, remember to copy the jar when we upgrade jetty etc etc. I'd prefer it be reopened, but I don't have the permission to do so. Happy to submit a patch...
Hide
Permalink
Greg Wilkins added a comment -

So how are you calling/starting Jetty?
I'd really prefer the extend the connector approach rather than have another if in the path
of every single request

Show
Greg Wilkins added a comment - So how are you calling/starting Jetty? I'd really prefer the extend the connector approach rather than have another if in the path of every single request
Hide
Permalink
Greg Wilkins added a comment -

Closing this as I think it can be done with extension even with a normal start jetty.xml setup.

Show
Greg Wilkins added a comment - Closing this as I think it can be done with extension even with a normal start jetty.xml setup.
Hide
Permalink
Ian Brandt added a comment -

Greetings. I stumbled onto this bug as I was trying to get Archiva Standalone 1.2.2, which out of the box embeds Jetty 6.1.19 configured with a non-SSL SelectChannelConnector, to play nice behind an Apache SSL proxy. I understand the desire not to add an 'if' check to every request. Would it be acceptable to add a SslProxiedSelectChannelConnector extends SelectChannelConnector or the like with the above customize(...) implementation to the core API? That way an some point in the future sysadmins who are deploying apps that embed Jetty could configure for Apache SSL proxying without having to write any Java themselves or deal with the classpath of the app or the JRE. You'd simply change the connector in the config. I'm happy to submit a patch if it would be welcomed.

Show
Ian Brandt added a comment - Greetings. I stumbled onto this bug as I was trying to get Archiva Standalone 1.2.2, which out of the box embeds Jetty 6.1.19 configured with a non-SSL SelectChannelConnector, to play nice behind an Apache SSL proxy. I understand the desire not to add an 'if' check to every request. Would it be acceptable to add a SslProxiedSelectChannelConnector extends SelectChannelConnector or the like with the above customize(...) implementation to the core API? That way an some point in the future sysadmins who are deploying apps that embed Jetty could configure for Apache SSL proxying without having to write any Java themselves or deal with the classpath of the app or the JRE. You'd simply change the connector in the config. I'm happy to submit a patch if it would be welcomed.
Hide
Permalink
Greg Wilkins added a comment -

Ian,

please do submit a patch.

However I'd be more inclined to have the extended class as a public inner class to SelectChannelConnector, rather than as an entirely new class.

cheers

Show
Greg Wilkins added a comment - Ian, please do submit a patch. However I'd be more inclined to have the extended class as a public inner class to SelectChannelConnector, rather than as an entirely new class. cheers
Hide
Permalink
Greg Wilkins added a comment -

waiting for patch

Show
Greg Wilkins added a comment - waiting for patch
Hide
Permalink
Greg Wilkins added a comment -

rewrite handler can do it in config
and can be done with simple extension.

Show
Greg Wilkins added a comment - rewrite handler can do it in config and can be done with simple extension.

People

Vote (0)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.