SSLServer responses hang and/or do not render.

[digitalextremist]

Similar to #80 if not the same.

Only able to use Curl and Safari so far, with Chrome and Firefox only working for a single pageload, some of the time. That single working pageload is usually a small icon, such a favicon.ico and nothing more. As I said, Safari and Curl work great... including Secure Web Sockets ( well, Safari at least ).

On Chrome and Firefox, usually/always the server hangs, even if refreshing that favicon.ico which previously worked ( once every few minutes ), and it needs to be stopped on the browser side. On the server side, a busy worker remains.

I inserted some debug output points, and I see that when the SSL server hangs, it is pipelining, and hanging on the second request on the connection... however there was never a first request to process! Safari and Curl show no pipelining.

[digitalextremist]

In that favicon.ico case that works, I've seen it pipeline also, and it does work... Not sure it why it's pipelining requests in that case, but it seems to pick up the ( single ) request anyway.

[digitalextremist]

In Chrome requests after the first one don't even hit the server at all.. In Firefox the second+ request does hit the server.

[Asmod4n]

Could you write a small repro?

[digitalextremist]

I am going to need time to extract a repro from my framework, but I am working on it.

In the meantime, I notice in Curl, the connection opens, gets its response, and immediately closes... which is explicitly done by my code ( it manually closes the connection ).

Under Safari, the previous connection closes only when another connection comes in. This doesn't seem to affect anything perceivable on the browser-side either way though.

Under Chrome, the second+ connection has no requests to process.

Under Firefox, it's intermittent. Whereas Chrome immediately fails ( and then hangs ), Safari never fails or hangs, Curl either, Firefox will succeed, then at some seemingly random point it accepts one request again, then becomes inaccessible again, etc.

[tarcieri]

Sounds like a pipelining bug of some sort. This is actually the sort of problem pipelining was supposed to address, and the symptoms sound similar to the pre-pipelining issue.

Can you reproduce it without SSL? That'd help simplify things...

What Ruby VMs is this occurring on?

[digitalextremist]

I am using jRuby 1.7.4

I have everything working fine without SSL.

There are two servers running in my stack, one SSL and one HTTP only; both use one request/response handler. WebSockets work on both protocols this way too.

As I said, Safari does great across all features.

I wonder if browsers' different handling of a socket are causing the pipelining to occur improperly? Maybe I ought to anticipate and work around that?

Also, how are environment variables intended to be handled when pipelining? Grab headers once and regrab different bodies, or regrab both headers and bodies per request ( in one connection )?

[digitalextremist]

The only issue I have with HTTP only is #90, related to pipelining too. Browsers all communicate fine with my stack's HTTP layer so long as I avoid Celluloid.defer {} for IO.copy_stream otherwise pipelining improperly occurs.

[tarcieri]

Again, "avoiding" Celluloid.defer is avoiding concurrency, which is probably not what you want

[digitalextremist]

I am avoiding avoiding Celluloid.defer {} but right now I am avoiding avoiding Nil response bodies in dev pageloads. By the time I ship this version I will get to the bottom of the my pipelining.

Question though, on new requests pipelined... do we pull new headers and body or just parse a new body with the same headers?

[digitalextremist]

Found the error, which was ( of course ) mine. This was very confusing to troubleshoot because of the individual browsers' behaviors. It was a prematurely closed socket, which was remnant code from the pre each_request update to Reel This debugging process also lead to the answer to #90 which I will post separately.