3 ms·

Is pipelining a well-defined behaviour now? I thought it was still pretty browser dependent. Obviously you need keep-alive for pipelining to work at all - but

by dedward 16y ago

Is pipelining a well-defined behaviour now? I thought it was still pretty browser dependent. Obviously you need keep-alive for pipelining to work at all - but are you saying you could actually dump responses down a keep-alive connection without corresponding requests and popular modern browsers will just deal with it?

jacquesm 16y ago
I've used it since (don't laugh) IE 3 came out because that was the only way to get decent performance out of it. Pipelining is a thing that is actually harder to guard against than to implement because as soon as keep-alive is on you can start sending multiple requests down the wire. The other side will presumably respond to the first request by scanning the input up and until the end of the request, then send back the result via the same connection. As soon as it has done that it will look for more input. Both sides can 'cheat', in other words, you don't actually need to look at the input requests when you're a server, and you don't actually need to wait for that first response to arrive before sending the next if your'e a client. The socket layer doesn't care one bit, to it it is all data, and the application layer presumably would have a hard time telling when certain bytes were sent if it is not explicitly polling the other side of the connection while generating another answer or reading a new request. So, typically the sequence on a keepalive connection looks like this: request - answer - request - answer - request - answer - etc But you could do this: (the google bot situation): request - request - request - answer - answer - answer - etc or even this (which is how my old webcam software worked): request - answer - answer - answer - request - request - etc So as soon as you switch on keep-alive you give the other side the opportunity to start pipe-lining requests or answers. The problem with the way the google bot works here is that they seem to log all the pipelined but as yet unanswered requests as 'failed' whereas they should only log the request that was next up for answering as failed. The obvious solutions are either keep alive 'off' for google or speed things up to the point where it will simply work.
- ivank 16y ago
  Just to reduce confusion (hopefully): > or even this (which is how my old webcam software worked): > request - answer - answer - answer - request - request - etc This is not HTTP pipelining, though it sort of looks similar. It's a neat hack, but the HTTP spec doesn't allow guessing what the request will be.
  - jacquesm 16y ago
    It doesn't say you can't either ;)

by dedward 16y ago

jacquesm 16y ago

I've used it since (don't laugh) IE 3 came out because that was the only way to get decent performance out of it. Pipelining is a thing that is actually harder to guard against than to implement because as soon as keep-alive is on you can start sending multiple requests down the wire. The other side will presumably respond to the first request by scanning the input up and until the end of the request, then send back the result via the same connection. As soon as it has done that it will look for more input. Both sides can 'cheat', in other words, you don't actually need to look at the input requests when you're a server, and you don't actually need to wait for that first response to arrive before sending the next if your'e a client. The socket layer doesn't care one bit, to it it is all data, and the application layer presumably would have a hard time telling when certain bytes were sent if it is not explicitly polling the other side of the connection while generating another answer or reading a new request. So, typically the sequence on a keepalive connection looks like this: request - answer - request - answer - request - answer - etc But you could do this: (the google bot situation): request - request - request - answer - answer - answer - etc or even this (which is how my old webcam software worked): request - answer - answer - answer - request - request - etc So as soon as you switch on keep-alive you give the other side the opportunity to start pipe-lining requests or answers. The problem with the way the google bot works here is that they seem to log all the pipelined but as yet unanswered requests as 'failed' whereas they should only log the request that was next up for answering as failed. The obvious solutions are either keep alive 'off' for google or speed things up to the point where it will simply work.

ivank 16y ago
Just to reduce confusion (hopefully): > or even this (which is how my old webcam software worked): > request - answer - answer - answer - request - request - etc This is not HTTP pipelining, though it sort of looks similar. It's a neat hack, but the HTTP spec doesn't allow guessing what the request will be.
- jacquesm 16y ago
  It doesn't say you can't either ;)