Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 349222

Summary:

Client fails to handle HTTPS Connection:close correctly

Product:

[RT] Jetty

Reporter:

Matt Painter <matthew.painter>

Component:

client

Assignee:

Jan Bartel <janb>

Status:

CLOSED WORKSFORME

QA Contact:

Severity:

critical

Priority:

CC:

jetty-inbox

Version:

8.0.0

Target Milestone:

7.2.x

Hardware:

OS:

Windows Server 2008

Whiteboard:

Attachments:

Description	Flags
Test program to try to reproduce reported problem	none

Description Matt Painter

2011-06-13 15:12:05 EDT

Client hangs when trying to download some URLs that return as Connection:close, .e.g

https://foretagsfakta.bolagsverket.se/fpl-dft-ext-web/error.seam;jsessionid=A21B164AC2F4F35F9ADEFA80053AA7BD.prod_fpl_node02?cid=78731

The closing of the connection is not picked up.

Comment 1 Matt Painter

2011-06-13 15:18:18 EDT

More examples of HttpExchange.onResponseComplete() not being called (all Connection:close):


https://www.psi.gov.sg/NASApp/tmf/TMFServlet?app=RCB-BIZFILE-LOGIN-1B

https://www.registro-publico.gob.pa/scripts/nwwisapi.dll/conweb/MESAMENU?TODO=MER4&FROM=&TO=&START=1&ID=

However, it's not always the case with Connection:close, e.g.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=349222

Comment 2 Matt Painter

2011-06-13 15:47:25 EDT

Using https://foretagsfakta.bolagsverket.se/fpl-dft-ext-web/error.seam;jsessionid=566D1E2796D47FFBCC8EA6ADA3C73CCB.prod_fpl_node01?cid=21942 as an example....

Whether connection:close is returned or not seems to be dependent upon the user agent, as these servers seem to use this rather than the HTTP request version to decide the HTTP version of the response (!).

If HTTP/1.1 is used, the servers use chunked encoding, and everything works. It is when they are using HTTP/1.0 that it is an issue.

Example user agent for 1.0:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618)

Example user agent for 1.1:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0C))

As such, it is probably a server issue, as this behaviour is just weird.

Comment 3 Jan Bartel

2011-06-24 00:26:17 EDT

Matt,

Which version of jetty are you using?

Do you have a wireshark or tcp dump of the http dialog?

I am a little confused about the scenario ... are you saying that you are using the jetty http client code to do these downloads and the client has a problem when HTTP/1.0 is used? Not sure where your user-agent strings come into play ... 

thanks
Jan

(In reply to comment #1)
> More examples of HttpExchange.onResponseComplete() not being called (all
> Connection:close):
> 
> 
> https://www.psi.gov.sg/NASApp/tmf/TMFServlet?app=RCB-BIZFILE-LOGIN-1B
> 
> https://www.registro-publico.gob.pa/scripts/nwwisapi.dll/conweb/MESAMENU?TODO=MER4&FROM=&TO=&START=1&ID=
> 
> However, it's not always the case with Connection:close, e.g.
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=349222

Comment 4 Jan Bartel

2011-06-30 01:51:52 EDT

Created attachment 198871 [details]
Test program to try to reproduce reported problem

Comment 5 Jan Bartel

2011-06-30 01:55:05 EDT

Matt,

I haven't been able to reproduce this problem with either jetty-7.4.3-SNAPSHOT nor jetty-8.0.0.M3 (you didn't say which jetty version you were using).

I've attached the test program I've been using.

Compile with:
  javac -cp [path to jetty-client aggregate jar] ClientTester.java

Run with:
  java -cp [path to jetty-client aggregate jar]:. ClientTester

I tried a few of the URLs and User-Agent combinations you posted, but haven't been able to induce any failures.

I will close the issue for now, but if you can provide further info, and a modified ClientTester.java that demonstrates the problem, please reopen.

thanks
Jan