Jetty

Chunked transfer encoding and SSL

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 6.1.18
  • Fix Version/s: 6.1.20
  • Component/s: Security and SSL
  • Labels:
    None
  • Number of attachments :
    1

Description

I am using transfer-encoding and Continuations quite happily and have been
for a while, which enables a Duplex Http connection. This works if I just use HTTP

The problem is when this happens through the SSL connector, no data is sent
to the client. The First part (Chunk) of the response is correctly written,
but not data reaches the client after that.

Is there something that has to happen differently when SSL is used over
chunked encoding?

The connections are still valid, and it is possible to write to the response
output stream, it just doesn't seem to be going on the wire.

The stream is being flushed, and I am wrapping the message in the correct
Chunked Encoding headers and this works a dream just using HTTP.

Its not a cert thing, as I can access the web server using https and the SSL
hadshake completes OK.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. JETTY-1087 Request chunking not working with HTTPS

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

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

Darren,

sorry but not enough information for us to investigate.

SSL definitely works with chunked responses
and it also works with continuations.

I don't have any test harnesses that do SSL with chunking and continuations, so I can't test exactly your use-case. If you could put together a simple test case that demonstrates this issue, then please re-open this issue.

Show
Greg Wilkins added a comment - Darren, sorry but not enough information for us to investigate. SSL definitely works with chunked responses and it also works with continuations. I don't have any test harnesses that do SSL with chunking and continuations, so I can't test exactly your use-case. If you could put together a simple test case that demonstrates this issue, then please re-open this issue.
Hide
Permalink
Darren Hudson added a comment -

Hi Greg, Here is what the servelt code is doing,

private void setUpDuplexConnection(HttpServletRequest request,
HttpServletResponse response) {

if(request.getAttribute(DUPLEX_REQUEST_ATTRIBUTE) != null)

{ // We have seen this before, so this must be the close request return; }

theLogger.fine("setUpDuplexConnection...");

Continuation continuation = null;

try {
HTTPDuplexClient client = new HTTPDuplexClient(request, response);

client.accept();

// Stop mux processing..
client.changeStateToProcessing();

client.handleHandshake();

TopicSet topicSet = new TopicSet(request
.getHeader(BaseWebClientDetail.TOPIC));

if (theLogger.isFineLogging())

{ theLogger.fine("DiffusionServlet: Adding client " + client.getClientID() + " with topics " + topicSet); }

// Do some topic stuff here...
client.clientSubscribe(topicSet);

client.notifyConnection();

theClients.put(client.getClientID(), client);

theDuplexClientProcessor.addDuplexClient(client);

request.setAttribute(DUPLEX_REQUEST_ATTRIBUTE, client.getClientID());

continuation = ContinuationSupport.getContinuation(
request, client);

client.setContinuation(continuation);
} catch (Exception ex)

{ theLogger.warning("Problem with Duplex request", ex); }

// Time to sleep
// NB: This throws a runtime exception, so make sure there is no catch
// try around the suspend
// Sleep for ever
continuation.suspend(0);
}

This works fine for normal HTTP transport, but when other thread sends information to the output stream and its SSL then the client never receives any responses

Show
Darren Hudson added a comment - Hi Greg, Here is what the servelt code is doing, private void setUpDuplexConnection(HttpServletRequest request, HttpServletResponse response) { if(request.getAttribute(DUPLEX_REQUEST_ATTRIBUTE) != null) { // We have seen this before, so this must be the close request return; } theLogger.fine("setUpDuplexConnection..."); Continuation continuation = null; try { HTTPDuplexClient client = new HTTPDuplexClient(request, response); client.accept(); // Stop mux processing.. client.changeStateToProcessing(); client.handleHandshake(); TopicSet topicSet = new TopicSet(request .getHeader(BaseWebClientDetail.TOPIC)); if (theLogger.isFineLogging()) { theLogger.fine("DiffusionServlet: Adding client " + client.getClientID() + " with topics " + topicSet); } // Do some topic stuff here... client.clientSubscribe(topicSet); client.notifyConnection(); theClients.put(client.getClientID(), client); theDuplexClientProcessor.addDuplexClient(client); request.setAttribute(DUPLEX_REQUEST_ATTRIBUTE, client.getClientID()); continuation = ContinuationSupport.getContinuation( request, client); client.setContinuation(continuation); } catch (Exception ex) { theLogger.warning("Problem with Duplex request", ex); } // Time to sleep // NB: This throws a runtime exception, so make sure there is no catch // try around the suspend // Sleep for ever continuation.suspend(0); } This works fine for normal HTTP transport, but when other thread sends information to the output stream and its SSL then the client never receives any responses
Hide
Permalink
Rob Beazizo added a comment -

This is happening for me too. I've attached a test program that reproduces the error.

Show
Rob Beazizo added a comment - This is happening for me too. I've attached a test program that reproduces the error.
Hide
Permalink
Rob Beazizo added a comment -

Hit ENTER too early :^(

Show
Rob Beazizo added a comment - Hit ENTER too early :^(
Hide
Permalink
Rob Beazizo added a comment -

Argh!

When "https" is true, the program reads the first 122 bytes then blocks on the second read at this stack when trying to read from the input stream on the servlet side:

Thread [1658468894@qtp0-4] (Suspended)
Object.wait(long) line: not available [native method] [local variables unavailable]
SslHttpChannelEndPoint(SelectChannelEndPoint).blockReadable(long) line: 243
HttpParser$Input.blockForContent() line: 1147
HttpParser$Input.read(byte[], int, int) line: 1103
HttpParser$Input(InputStream).read(byte[]) line: 85
ChunkingTest$Test.doPost(HttpServletRequest, HttpServletResponse) line: 70
ChunkingTest$Test(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 760
ChunkingTest$Test(HttpServlet).service(ServletRequest, ServletResponse) line: 853
ServletHolder.handle(ServletRequest, ServletResponse) line: 502
ServletHandler.handle(String, HttpServletRequest, HttpServletResponse, int) line: 363
Server(HandlerWrapper).handle(String, HttpServletRequest, HttpServletResponse, int) line: 152
Server.handle(HttpConnection) line: 324
HttpConnection.handleRequest() line: 534
HttpConnection$RequestHandler.content(Buffer) line: 879
HttpParser.parseNext() line: 828
HttpParser.parseAvailable() line: 207
HttpConnection.handle() line: 403
SslHttpChannelEndPoint(SelectChannelEndPoint).run() line: 409
QueuedThreadPool$PoolThread.run() line: 522

When "https" is false, then you see the output:

read chunk: 122
read chunk: 122
NEVER GETS HERE WHEN SERVER IS HTTPS !!!!!

Anyways, probably something I'm doing wrong.

Show
Rob Beazizo added a comment - Argh! When "https" is true, the program reads the first 122 bytes then blocks on the second read at this stack when trying to read from the input stream on the servlet side: Thread [1658468894@qtp0-4] (Suspended) Object.wait(long) line: not available [native method] [local variables unavailable] SslHttpChannelEndPoint(SelectChannelEndPoint).blockReadable(long) line: 243 HttpParser$Input.blockForContent() line: 1147 HttpParser$Input.read(byte[], int, int) line: 1103 HttpParser$Input(InputStream).read(byte[]) line: 85 ChunkingTest$Test.doPost(HttpServletRequest, HttpServletResponse) line: 70 ChunkingTest$Test(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 760 ChunkingTest$Test(HttpServlet).service(ServletRequest, ServletResponse) line: 853 ServletHolder.handle(ServletRequest, ServletResponse) line: 502 ServletHandler.handle(String, HttpServletRequest, HttpServletResponse, int) line: 363 Server(HandlerWrapper).handle(String, HttpServletRequest, HttpServletResponse, int) line: 152 Server.handle(HttpConnection) line: 324 HttpConnection.handleRequest() line: 534 HttpConnection$RequestHandler.content(Buffer) line: 879 HttpParser.parseNext() line: 828 HttpParser.parseAvailable() line: 207 HttpConnection.handle() line: 403 SslHttpChannelEndPoint(SelectChannelEndPoint).run() line: 409 QueuedThreadPool$PoolThread.run() line: 522 When "https" is false, then you see the output: read chunk: 122 read chunk: 122 NEVER GETS HERE WHEN SERVER IS HTTPS !!!!! Anyways, probably something I'm doing wrong.
Hide
Permalink
Rob Beazizo added a comment -

Slight problem with the first version, this one is more correct...

Show
Rob Beazizo added a comment - Slight problem with the first version, this one is more correct...
Hide
Permalink
Rob Beazizo added a comment -

Also, note that I've tried both JDK 1.5 and 1.6, and both have the same problem.

Show
Rob Beazizo added a comment - Also, note that I've tried both JDK 1.5 and 1.6, and both have the same problem.
Hide
Permalink
Rob Beazizo added a comment -

I also tried changing the test program to use Apache HttpClient instead of HttpsURLConnection (and using its chunking). It resulted in the same problem on the server side.

Show
Rob Beazizo added a comment - I also tried changing the test program to use Apache HttpClient instead of HttpsURLConnection (and using its chunking). It resulted in the same problem on the server side.
Hide
Permalink
Greg Wilkins added a comment -

This looks to be the same

Show
Greg Wilkins added a comment - This looks to be the same
Hide
Permalink
Greg Wilkins added a comment -

This was fixed as JETTY-1087 and your test program works in 6.1.20

Show
Greg Wilkins added a comment - This was fixed as JETTY-1087 and your test program works in 6.1.20

People

  • Assignee:
    Greg Wilkins
    Reporter:
    Darren Hudson
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: