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 2020/06/12 16:07:20 UTC

[GitHub] [incubator-pagespeed-ngx] adrelanos opened a new issue #1694: document good origin HTTP header settings / nginx config / etags / nginx pagespeed output headers

adrelanos opened a new issue #1694:
URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1694


   What are some good combinations of HTTP headers? What should users of pagespeed check their webapps are outputting wrt HTTP headers? Are there some good examples of recommended origin caching HTTP headers? Perhaps there are multiple valid combinations? Or good websites that have good caching settings which are a good role model?
   
   Could you please provide a basic nginx config for static contents? There's a lot. Expires; HTTP ETag; weak ETag; vs gzip; last modified. It's still unclear the me which combination of settings / HTTP headers are a good basis for pagespeed to work with.
   
   Pagespeed showing an `Etag: W/"0"` being for cachable static files is expected or a bug?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[GitHub] [incubator-pagespeed-ngx] Lofesa edited a comment on issue #1694: document good origin HTTP header settings / nginx config / etags / nginx pagespeed output headers

Posted by GitBox <gi...@apache.org>.
Lofesa edited a comment on issue #1694:
URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1694#issuecomment-643370757


   Pagespeed don´t care about what headers are you using, the only thing that matters is public cacheability. When a resource is optimized, then pagespeed put 1 year for ttl.
   The html himself is served whit cache-control header with max-age=0, so is not stored in any cache.
   The etag:W/"0" is the expected behaviour. The W is a weak validator, resource are semanticaly the same, but not byte by byte. [(doc)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[GitHub] [incubator-pagespeed-ngx] oschaaf closed issue #1694: document good origin HTTP header settings / nginx config / etags / nginx pagespeed output headers

Posted by GitBox <gi...@apache.org>.
oschaaf closed issue #1694:
URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1694


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[GitHub] [incubator-pagespeed-ngx] Lofesa commented on issue #1694: document good origin HTTP header settings / nginx config / etags / nginx pagespeed output headers

Posted by GitBox <gi...@apache.org>.
Lofesa commented on issue #1694:
URL: https://github.com/apache/incubator-pagespeed-ngx/issues/1694#issuecomment-643370757


   Pagespeed don´t care about what headers are you using, the only thing that matters is public cacheability. Whe a resource is optimized, then pagespeed put 1 year for ttl.
   The html himself is served whit cache-control header with max-age=0, so is not stored in any cache.
   The etag:W/"0" is the expected behaviour. The W is a weak validator, resource are semanticaly the same, but not byte by byte. [(doc)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag)
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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