You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pagespeed.apache.org by GitBox <gi...@apache.org> on 2018/05/09 08:00:00 UTC
[GitHub] jstangroome opened a new issue #1556: Combined css returns
truncated, mis-encoded body on cache hit
jstangroome opened a new issue #1556: Combined css returns truncated, mis-encoded body on cache hit
URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1556
PageSpeed 1.13.35.2 on nginx 1.13.8 on Ubuntu 14.04 (and on Minikube).
Original HTML contains:
```
<head>
<link rel="stylesheet" href="/css/store.css" type="text/css" />
<link rel="stylesheet" href="/css/vendor.css" type="text/css" />
```
Rewritten HTML contains:
```
<head>
<link rel="stylesheet" href="/css/A.store.css+vendor.css,Mcc.HBFc8IpUqh.css.pagespeed.cf.OBCdvpW_8K.css" type="text/css"/>
```
The first request for `/css/A.store.css+vendor.css,Mcc.HBFc8IpUqh.css.pagespeed.cf.OBCdvpW_8K.css` (ie cache miss) with `Accept-Encoding: gzip` correctly returns the a gzipped response body with the combined contents of the two CSS files. The response header is `Content-Encoding: gzip` and the body is 137,582 bytes gzipped, and 650,422 bytes after inflating.
The second and subsequent requests (whilst the cache remains valid) still return the `Content-Encoding: gzip` response header but the response body is not gzipped, just the uncompressed CSS, and the CSS is truncated at 105,759 bytes which matches the `Content-Length` response header also returned. This length of ~105KiB bears no relationship to either of the two included CSS files, in their original or gzipped forms.
If the pagespeed cache is allowed to expire naturally, or if the cache is explicitly purged with a `PURGE` HTTP request, the next immediate request will succeed again, but then future requests will return to the truncated and mis-encoded behaviour.
The behaviour is the same regardless of whether PageSpeed is configured to use memcached or file cache. When using file cache, the combined CSS files on the local PageSpeed disk contains the `Content-Length: 105759` header in the cache file preamble. The original, successful request either uses `Transfer-Encoding: Chunked` or `Connection: Close` and never included this `Content-Length` response header.
Any requests for the non-gzipped resources (ie by excluding the `Accept-Encoding: gzip` request header) work correctly regardless of whether the object is already cached or not. Requests for non-gzipped responses also include the correct response header of `Content-Length: 650423`.
If I modify the combined CSS URL to exclude `store.css`, ie `/css/A.vendor.css,Mcc.HBFc8IpUqh.css.pagespeed.cf.OBCdvpW_8K.css` then PageSpeed works correctly, never truncating or mis-encoding the response. However, if I exclude `vendor.css` instead resulting in `/css/A.store.css,Mcc.HBFc8IpUqh.css.pagespeed.cf.OBCdvpW_8K.css` then requests for this URL experience the same mis-encoding problem on the cache hits.
The configured pagespeed directives in nginx.conf are:
```
pagespeed On;
pagespeed EnableCachePurge on;
pagespeed RewriteLevel PassThrough;
pagespeed InPlaceResourceOptimization on;
pagespeed FetchHttps enable;
pagespeed CustomFetchHeader X-Forwarded-Proto https;
pagespeed PreserveUrlRelativity on;
pagespeed EnableFilters "add_head,combine_css,combine_javascript,convert_meta_tags,extend_cache,fallback_rewrite_css_urls,flatten_css_imports,inline_css,inline_import_to_link,inline_javascript,rewrite_css,rewrite_images,rewrite_javascript,rewrite_style_attributes_with_url";
```
Is this enough information for you to identify the problematic code path in the PageSpeed source? What more do I need to provide to diagnose this bug?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services