From: Nicolas T. <ni...@co...> - 2014-01-17 10:11:43
|
Hi ! While trying to play with Google PageSpeed Insights, our website was reported as "not using compression for JS & CSS files" whereas the "deflate" option was correctly set in the config file. Actually, this Google bot sends two headers "Accept-Encoding:gzip,deflate" when requesting those files, which results in a weirdness inside yaws.erl : accepts_gzip(H, Mime) -> case [Val || {_,_,'Accept-Encoding',_,Val}<- H#headers.other] of [] -> false; [AcceptEncoding] -> [...]; _ -> false end. The third branch wins, and gzip is disabled. I patched the second match as [AcceptEncoding | _] to pass Insights tests, but I wonder what behavior is expected according to the RFCs : * concatenate the list of all encodings in all headers ? * take the first header ? * ... ? It looks like a bug on Google side (I wrote a comment in the Insights tool), but Yaws' reply seems weird to me ! Cheers, -- Nicolas |
From: Steve V. <vi...@ie...> - 2014-01-17 16:10:47
|
On Fri, Jan 17, 2014 at 4:44 AM, Nicolas Thauvin <ni...@co...>wrote: > Hi ! > > While trying to play with Google PageSpeed Insights, our website was > reported as "not using compression for JS & CSS files" whereas the > "deflate" option was correctly set in the config file. > > Actually, this Google bot sends two headers "Accept-Encoding:gzip,deflate" > when requesting those files, which results in a weirdness inside yaws.erl : > > accepts_gzip(H, Mime) -> > case [Val || {_,_,'Accept-Encoding',_,Val}<- H#headers.other] of > [] -> > false; > [AcceptEncoding] -> > [...]; > _ -> false > end. > > The third branch wins, and gzip is disabled. I patched the second match as > [AcceptEncoding | _] to pass Insights tests, but I wonder what behavior is > expected according to the RFCs : > * concatenate the list of all encodings in all headers ? > * take the first header ? > * ... ? > According to HTTP 1.1 section 4.2, a receiver may combine multiple instances of any header whose value can be a comma-separated list, which applies in this case. Looks like HTTPbis in section 3.2.2 keeps the same rule. So, technically Yaws should be combining the multiple Accept-Encoding headers into one here. I'll make that change. It looks like a bug on Google side (I wrote a comment in the Insights > tool), but Yaws' reply seems weird to me ! > I think the Google side is OK in this case. --steve |
From: Steve V. <vi...@ie...> - 2014-01-17 22:17:08
|
On Fri, Jan 17, 2014 at 11:10 AM, Steve Vinoski <vi...@ie...> wrote: > > > > On Fri, Jan 17, 2014 at 4:44 AM, Nicolas Thauvin <ni...@co...>wrote: > >> Hi ! >> >> While trying to play with Google PageSpeed Insights, our website was >> reported as "not using compression for JS & CSS files" whereas the >> "deflate" option was correctly set in the config file. >> >> Actually, this Google bot sends two headers "Accept-Encoding:gzip,deflate" >> when requesting those files, which results in a weirdness inside yaws.erl >> : >> >> accepts_gzip(H, Mime) -> >> case [Val || {_,_,'Accept-Encoding',_,Val}<- H#headers.other] of >> [] -> >> false; >> [AcceptEncoding] -> >> [...]; >> _ -> false >> end. >> >> The third branch wins, and gzip is disabled. I patched the second match as >> [AcceptEncoding | _] to pass Insights tests, but I wonder what behavior is >> expected according to the RFCs : >> * concatenate the list of all encodings in all headers ? >> * take the first header ? >> * ... ? >> > > According to HTTP 1.1 section 4.2, a receiver may combine multiple > instances of any header whose value can be a comma-separated list, which > applies in this case. Looks like HTTPbis in section 3.2.2 keeps the same > rule. So, technically Yaws should be combining the multiple Accept-Encoding > headers into one here. I'll make that change. > Now fixed on Yaws master at github. Thanks for reporting this. --steve |