6 ms·

I really miss old Opera which correctly implemented HTTP pipelining[1] :/ [1] https://en.wikipedia.org/wiki/HTTP_pipelining https://en.wikipedia.org/wiki/HTTP_

by takeda 7y ago

I really miss old Opera which correctly implemented HTTP pipelining[1] :/ [1] https://en.wikipedia.org/wiki/HTTP_pipelining https://en.wikipedia.org/wiki/HTTP_pipelining Edit: article also doesn't mention about keep-alive, in fact it explicitly states that HTTP/1.1 opens one connection per request which is not true. Makes me think that the HTTP/1.1 demo disables KA to make effect even more dramatic. Edit2: demos don't make actual network requests.

Thaxll 7y ago
It's hard to know if it was correctly implemented knowing that other wouldn't implement it because of major issues.
- takeda 7y ago
  As an Opera user from 2003 to 2016 (when they decided to drop Presto) I don't remember having any issues with it.
  - bsdetector 7y ago
    Has anybody ever given any even halfway compelling evidence of pipelining breaking websites? Google didn't, Mozilla didn't. I believe there was one small banking site using a ten year old IIS that didn't load - but maybe pipelining was the least of the problems there. Another that sent the wrong images to mobile Safari, or mobile Safari displayed them wrong, but was fixed. Pipelining may not have been the technically best solution, but it certainly would have taken the impetus away from SPDY. If Mozilla had shown the courage to default to pipelining maybe the industry as a whole could have had some input on HTTP/2 instead of just rubber-stamping SPDY.
    - toast0 7y ago
      There's several bug reports attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://bugzilla.mozilla.org/show_bug.cgi?id=264354 This probably could have been solved for HTTPS though, if you negotiate to http/1.1 via ALPN, then pipelining could be OK? Otherwise, http/1.1 with keepalive only should be used?
      - bsdetector 7y ago
        These are bugs in Firefox. There were bugs in their HTTP/2 implementation as well. The comments show that Mozilla was frozen by fear of some unknown problems happening if they enabled pipelining.
        toast0 7y ago
        Ok, well there's this bug too https://github.com/elastic/elasticsearch/issues/2665 https://github.com/elastic/elasticsearch/issues/2665 But now you're going to say that's a bug in a specific brain dead server, and it should have been fixed. I'm sure there are other bugs tracking other server's issues with pipelining, but that's the only one I remember seeing (mostly because of the amazingly terrible nature of the bug). The point of the Bugzilla link is that enabling pipelining in Firefox would trigger bad behavior in servers. It's not some idle fear of unknown problems, it's fear informed by actual problems -- if you turn on the feature mostly things will work fine, but some stuff is going to break, and user interpretation when Firefox gets a broken page and IE (or Chrome, whatever) works, is that it must be Firefox's fault. There's not necessarily a way to detect an error in this case, so it's hard to gracefully degrade. The exciting world of (mostly) transparent proxies for plaintext http makes this even worse.
        bsdetector 7y ago
        I think you're really making my point for me. There were hundreds of millions of Opera and mobile Safari users with pipelining enabled, and the only problems you can point to are a few small things, in this case in something that doesn't even seem to be normally accessed from a browser.
        Galanwe 7y ago
        I wrote a somewhat performance oriented web server some years ago, and wondered whether I should implement pipelining. My conclusion was that pipelining is unusable in HTTP 1.x, and a potentially harmful behaviour for the server. See, the problem is that there is no way in HTTP 1.x to map server responses to client requests. That is why the server has to send responses in the same order it received requests. This is disastrous for the server, because it means each response should be buffered until it can be sent at its correct order. If you send 100 requests to the server, and the first one is slower to compute than the others, then you effectively need to buffer 99 responses until the first one finishes to send everything. I'm not even sure the client would benefit much from pipelining versus concurrent requests, because the client would have to know how to order requests so that a GET for a big image does not block the whole pipeline because it was made before the small images. If there was a way in HTTP 1.x to identify which response is for which request, then the server would be able to send responses in any order it can, and it would have been usable.
  - pilif 7y ago
    As an Opera user you were not very likely to be behind some middlebox. Middleboxes interfering with pipelined traffic was the reason it was never safe to enable by default.
    - takeda 7y ago
      Why being Opera user made me less likely to be behind a middlebox? I installed Opera wherever I was accessing the Internet. I think only place that they had heavy restrictions was a community college which restricted browser to IE, but I was able to use Opera from a thumb drive. Never had issues.
      - pilif 7y ago
        Because people most likely behind a badly maintained middlebox aren't allowed to pick, much less install a browser of their choosing.
3xblah 7y ago
It appears the author did not test HTTP/1.1 pipelining Something like n=1;while :;do test $n -le 7||break; printf "GET /articles/"$n" HTTP/1.1\r\nHost: api.example.org\r\nConnection: "; if test $n = 7;then printf "close\r\n\r\n";else printf "keep-alive\r\n\r\n";fi; n=$((n+1)); done|openssl s_client -connect api.example.org:443 -ign_eof
- treve 7y ago
  No, I definitely didn't. Pipelining is not supported in any browser, and I was mostly looking for the current state of what's possible.
- cryptonector 7y ago
  Pipelining has been removed. Sadness.
  - 3xblah 7y ago
    I have never seen it removed from a server. It is an option that some website operators may disable. However most sites enable it, or the httpd they use has it enabled by default.
    - cryptonector 7y ago
      Ok, sure, but if the clients don't implement it... does it matter that some servers do? EDIT: Well, maybe it does matter. E.g., if it creates request smuggling vulnerabilities, say, in the presence of reverse proxies that don't interpret the spec the same as the servers.
      - 3xblah 7y ago
        I like pipelining as a 1.1 feature. I have successfully used TCP/TLS clients like netcat and openssl to retrieve text/html in bulk for many years. The servers always worked great for me. However I never liked chunked encoding as a feature. In theory it sounds reasonable but in practice it is a hassle. As TE chunked became more widespread eventually I had to write a filter to process it. It is not perfect but it seems to work. Not surprised chunked encoding can cause problems on the server-side. NetBSD has a httpd that tries to be standards-compliant but still has not implemented chunked requests.

by takeda 7y ago

Thaxll 7y ago

It's hard to know if it was correctly implemented knowing that other wouldn't implement it because of major issues.

takeda 7y ago
As an Opera user from 2003 to 2016 (when they decided to drop Presto) I don't remember having any issues with it.
- bsdetector 7y ago
  Has anybody ever given any even halfway compelling evidence of pipelining breaking websites? Google didn't, Mozilla didn't. I believe there was one small banking site using a ten year old IIS that didn't load - but maybe pipelining was the least of the problems there. Another that sent the wrong images to mobile Safari, or mobile Safari displayed them wrong, but was fixed. Pipelining may not have been the technically best solution, but it certainly would have taken the impetus away from SPDY. If Mozilla had shown the courage to default to pipelining maybe the industry as a whole could have had some input on HTTP/2 instead of just rubber-stamping SPDY.
  - toast0 7y ago
    There's several bug reports attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://bugzilla.mozilla.org/show_bug.cgi?id=264354 This probably could have been solved for HTTPS though, if you negotiate to http/1.1 via ALPN, then pipelining could be OK? Otherwise, http/1.1 with keepalive only should be used?
    - bsdetector 7y ago
      These are bugs in Firefox. There were bugs in their HTTP/2 implementation as well. The comments show that Mozilla was frozen by fear of some unknown problems happening if they enabled pipelining.
      - toast0 7y ago
        Ok, well there's this bug too https://github.com/elastic/elasticsearch/issues/2665 https://github.com/elastic/elasticsearch/issues/2665 But now you're going to say that's a bug in a specific brain dead server, and it should have been fixed. I'm sure there are other bugs tracking other server's issues with pipelining, but that's the only one I remember seeing (mostly because of the amazingly terrible nature of the bug). The point of the Bugzilla link is that enabling pipelining in Firefox would trigger bad behavior in servers. It's not some idle fear of unknown problems, it's fear informed by actual problems -- if you turn on the feature mostly things will work fine, but some stuff is going to break, and user interpretation when Firefox gets a broken page and IE (or Chrome, whatever) works, is that it must be Firefox's fault. There's not necessarily a way to detect an error in this case, so it's hard to gracefully degrade. The exciting world of (mostly) transparent proxies for plaintext http makes this even worse.
        bsdetector 7y ago
        I think you're really making my point for me. There were hundreds of millions of Opera and mobile Safari users with pipelining enabled, and the only problems you can point to are a few small things, in this case in something that doesn't even seem to be normally accessed from a browser.
        Galanwe 7y ago
        I wrote a somewhat performance oriented web server some years ago, and wondered whether I should implement pipelining. My conclusion was that pipelining is unusable in HTTP 1.x, and a potentially harmful behaviour for the server. See, the problem is that there is no way in HTTP 1.x to map server responses to client requests. That is why the server has to send responses in the same order it received requests. This is disastrous for the server, because it means each response should be buffered until it can be sent at its correct order. If you send 100 requests to the server, and the first one is slower to compute than the others, then you effectively need to buffer 99 responses until the first one finishes to send everything. I'm not even sure the client would benefit much from pipelining versus concurrent requests, because the client would have to know how to order requests so that a GET for a big image does not block the whole pipeline because it was made before the small images. If there was a way in HTTP 1.x to identify which response is for which request, then the server would be able to send responses in any order it can, and it would have been usable.
- pilif 7y ago
  As an Opera user you were not very likely to be behind some middlebox. Middleboxes interfering with pipelined traffic was the reason it was never safe to enable by default.
  - takeda 7y ago
    Why being Opera user made me less likely to be behind a middlebox? I installed Opera wherever I was accessing the Internet. I think only place that they had heavy restrictions was a community college which restricted browser to IE, but I was able to use Opera from a thumb drive. Never had issues.
    - pilif 7y ago
      Because people most likely behind a badly maintained middlebox aren't allowed to pick, much less install a browser of their choosing.

3xblah 7y ago

It appears the author did not test HTTP/1.1 pipelining Something like n=1;while :;do test $n -le 7||break; printf "GET /articles/"$n" HTTP/1.1\r\nHost: api.example.org\r\nConnection: "; if test $n = 7;then printf "close\r\n\r\n";else printf "keep-alive\r\n\r\n";fi; n=$((n+1)); done|openssl s_client -connect api.example.org:443 -ign_eof

treve 7y ago
No, I definitely didn't. Pipelining is not supported in any browser, and I was mostly looking for the current state of what's possible.
cryptonector 7y ago
Pipelining has been removed. Sadness.
- 3xblah 7y ago
  I have never seen it removed from a server. It is an option that some website operators may disable. However most sites enable it, or the httpd they use has it enabled by default.
  - cryptonector 7y ago
    Ok, sure, but if the clients don't implement it... does it matter that some servers do? EDIT: Well, maybe it does matter. E.g., if it creates request smuggling vulnerabilities, say, in the presence of reverse proxies that don't interpret the spec the same as the servers.
    - 3xblah 7y ago
      I like pipelining as a 1.1 feature. I have successfully used TCP/TLS clients like netcat and openssl to retrieve text/html in bulk for many years. The servers always worked great for me. However I never liked chunked encoding as a feature. In theory it sounds reasonable but in practice it is a hassle. As TE chunked became more widespread eventually I had to write a filter to process it. It is not perfect but it seems to work. Not surprised chunked encoding can cause problems on the server-side. NetBSD has a httpd that tries to be standards-compliant but still has not implemented chunked requests.