Varnish shouldn't test gunzip for range responses #2530
Labels
Comments
|
I'm using this issue also as a placeholder for a collateral bug found while working on this, regarding ESI and partial responses. The reasons why it took so long to send the patches despite having them ready at the time are 1) I was sick that week 2) I found the ESI bug and 3) it got OBE. Sorry about the latter. |
Dridi
added a commit
to Dridi/varnish-cache
that referenced
this issue
Jan 31, 2018
Some user agents like Safari may "probe" specific resources like medias
before getting the full resources usually asking for the first 2 or 11
bytes, probably to peek at magic numbers to figure early whether a
potentially large resource may not be supported (read: video).
If the user agent also advertises gzip support, and the transaction is
known beforehand to not be cacheable, varnishd will forward the Range
header to the backend:
Accept-Encoding: gzip (when http_gzip_support is on)
Range: bytes=0-1
If the response happens to be both encoded and partial, the gunzip test
cannot be performed. Otherwise we systematically end up with a broken
transaction closed prematuraly:
FetchError b tGunzip failed
Gzip b u F - 2 0 0 0 0
Refs varnishcache#2530
Dridi
added a commit
to Dridi/varnish-cache
that referenced
this issue
Jan 31, 2018
Otherwise we can't reliably parse the response body looking for ESI tags. Instead a workaround is available in VCL and documented, and the regression test exercises a similar workaround. Bonus whitespace and RST cleanup in the ESI guide. Fixes varnishcache#2530
|
Go see #2554 instead |
Dridi
added a commit
that referenced
this issue
Feb 23, 2018
Some user agents like Safari may "probe" specific resources like medias
before getting the full resources usually asking for the first 2 or 11
bytes, probably to peek at magic numbers to figure early whether a
potentially large resource may not be supported (read: video).
If the user agent also advertises gzip support, and the transaction is
known beforehand to not be cacheable, varnishd will forward the Range
header to the backend:
Accept-Encoding: gzip (when http_gzip_support is on)
Range: bytes=0-1
If the response happens to be both encoded and partial, the gunzip test
cannot be performed. Otherwise we systematically end up with a broken
transaction closed prematuraly:
FetchError b tGunzip failed
Gzip b u F - 2 0 0 0 0
Refs #2530
Refs #2554
Dridi
added a commit
that referenced
this issue
Feb 23, 2018
Some user agents like Safari may "probe" specific resources like medias
before getting the full resources usually asking for the first 2 or 11
bytes, probably to peek at magic numbers to figure early whether a
potentially large resource may not be supported (read: video).
If the user agent also advertises gzip support, and the transaction is
known beforehand to not be cacheable, varnishd will forward the Range
header to the backend:
Accept-Encoding: gzip (when http_gzip_support is on)
Range: bytes=0-1
If the response happens to be both encoded and partial, the gunzip test
cannot be performed. Otherwise we systematically end up with a broken
transaction closed prematuraly:
FetchError b tGunzip failed
Gzip b u F - 2 0 0 0 0
Refs #2530
Refs #2554
slimhazard
added a commit
that referenced
this issue
Feb 25, 2018
Storage defaults to umem where libumem is available, as is usually the case on SunOS. So checking SMA.* stats was causing the test to fail on Solaris.
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
Some user agents like Safari may "probe" specific resources like medias
before getting the full resources usually asking for the first 2 or 11
bytes, probably to peek at magic numbers to figure early whether a
potentially large resource may not be supported (read: video).
If the user agent also advertises gzip support, and the transaction is
known beforehand to not be cacheable, varnishd will forward the Range
header to the backend:
Accept-Encoding: gzip (when http_gzip_support is on)
Range: bytes=0-1
If the response happens to be both encoded and partial, the gunzip test
cannot be performed. Otherwise we systematically end up with a broken
transaction closed prematuraly:
FetchError b tGunzip failed
Gzip b u F - 2 0 0 0 0
Refs varnishcache#2530
Refs varnishcache#2554
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
…#2530. Storage defaults to umem where libumem is available, as is usually the case on SunOS. So checking SMA.* stats was causing the test to fail on Solaris.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a placeholder, I will close this issue once fixed in both master and 4.1 branches. Confirmed for any version since at least 4.0, and I have a patch for trunk. I will submit the first patch once I have a more comprehensive test case.
The text was updated successfully, but these errors were encountered: