[grizzly-provider] connection abort, when neither transfer-encoding nor content-length is specified

[oleksiys]

[mirror of https://java.net/jira/browse/GRIZZLY-1679]

We at Strucr use the Grizzly HTTP Client to crawl a lot of sites, and we again and again have problems where Grizzly incorrectly reports a connection as having been remotely closed, that indeed was not.

The behavior is triggered by a HTTP response that

has no content-length, but
also has Connection: Close

Like this:

HTTP/1.0 200 OK
Date: Tue, 29 Apr 2014 22:18:06 GMT
Server: Apache
Cache-Control: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: close
Content-Type: text/plain; charset=UTF-8

The according request was sent as keep-alive:

GET /robots.txt HTTP/1.1
Host: www.aroundtheglobe.nl
Connection: keep-alive

The issue also occurs if the response is HTTP 1.1.

Grizzyl in this case throws an java.io.IOException: Remotely Closed

This is the stack trace:

com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$AsyncHttpClientTransportFilter$1.failed(GrizzlyAsyncHttpProvider.java:761),
org.glassfish.grizzly.filterchain.DefaultFilterChain.notifyFailure(DefaultFilterChain.java:617),
org.glassfish.grizzly.filterchain.DefaultFilterChain.throwChain(DefaultFilterChain.java:493),
org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:165),
org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115),
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77),
org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550),
org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112),
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117),
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56),
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137),
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146),
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615),
java.lang.Thread.run(Thread.java:701)

The behavior is reproducible, and we also tested against but do not have the problem with

Netty,
Apache HTTP Client and
Java URL

All major browsers work, too.

Since the Content-Length header is not required, but only SHOULD be send in a response, we believe this is a bug of Grizzly.

[oleksiys]

fixed