Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple etag problems with directory handler causing browser use outdated cached content. #2628

Closed
vshab opened this issue Jul 4, 2015 · 8 comments
Assignees
Labels
Milestone

Comments

@vshab
Copy link

@vshab vshab commented Jul 4, 2015

Server doesn't return etag at first request

  1. Start simple server with directory handler setup.

  2. Open Chrome with Developer tools enabled.

  3. Select network tab and check "Disable cache" box.

  4. Request some file and look for header.

    Request Method:GET
    Status Code:200 OK
    
    Response Headers
    cache-control:no-cache
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:no-cache
    Pragma:no-cache
    
  5. Repeat the request.

    Request Method:GET
    Status Code:200 OK
    
    Response Headers
    cache-control:no-cache
    etag:"c1fe76b955c011b7b507ea734f09f30750242f32-gzip"
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:no-cache
    Pragma:no-cache
    

Server returns inconsistent etag value

  1. Start simple server with directory handler setup.

  2. Open Chrome with Developer tools enabled.

  3. Select network tab and check "Disable cache" box.

  4. Request some file and look for header.

    Request Method:GET
    Status Code:200 OK
    
    Response Headers
    cache-control:no-cache
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:no-cache
    Pragma:no-cache
    
  5. Uncheck "Disable cache" box.

  6. Repeat the request.

    Request Method:GET
    Status Code:304 Not Modified
    
    Response Headers
    cache-control:no-cache
    etag:"c1fe76b955c011b7b507ea734f09f30750242f32"
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:max-age=0
    If-Modified-Since:Fri, 03 Jul 2015 15:45:40 GMT
    

etag in the response differs from etag from previous case(no "-gzip").

In some cases server calculates wrong etag.

This is more complecated but the most problematic case.

  1. There are two files with different modified date and etag calculated as in first case

    • File A with 2015-07-03 22:46:00.978516332. etag 614772fb23d14140032c2533941df7b54f04d3db-gzip
    • File B with 2015-07-03 22:45:40.483031076. etag c1fe76b955c011b7b507ea734f09f30750242f32-gzip
  2. Start simple server with directory handler setup.

  3. Copy File A as "file" into serving directory

  4. Open Chrome with Developer tools enabled.

  5. Select network tab and check "Disable cache" box.

  6. Request the "file" and look for header.

    Request Method:GET
    Status Code:200 OK
    
    Response Headers
    cache-control:no-cache
    last-modified:Fri, 03 Jul 2015 15:46:00 GMT
    
    Request Headers
    Cache-Control:no-cache
    Pragma:no-cache
    
  7. Replace "file" from serving directory with File B

  8. Uncheck "Disable cache" box.

  9. Repeat the request.

    Request Method:GET
    Status Code:304 Not Modified
    
    Response Headers
    cache-control:no-cache
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:max-age=0
    If-Modified-Since:Fri, 03 Jul 2015 15:46:00 GMT
    

    BUG: Browser didn't get File B, instead it still use cached File A.

  10. Repeat the request.

    Request Method:GET
    Status Code:304 Not Modified
    
    Response Headers
    cache-control:no-cache
    etag:"da39a3ee5e6b4b0d3255bfef95601890afd80709"
    last-modified:Fri, 03 Jul 2015 15:45:40 GMT
    
    Request Headers
    Cache-Control:max-age=0
    If-Modified-Since:Fri, 03 Jul 2015 15:45:40 GMT
    

    BUG: etag is some random "da39a3ee5e6b4b0d3255bfef95601890afd80709" which is not File A nor File B. Slightly looking into the code i found that Hapi even doesn't read content of File B so it can't calculate etag.

There are a lot of text, but I hope it will help fixing the bugs. Because in current state there are really problems with updating static content when updating file with greater modified time.

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Jul 4, 2015

Can you open this issue again in the inert repository? All this is handled by the plugin, not hapi itself. I'm sure @kanongil will look into it.

@hueniverse hueniverse closed this Jul 4, 2015
@hueniverse hueniverse self-assigned this Jul 4, 2015
@kanongil
Copy link
Contributor

@kanongil kanongil commented Jul 4, 2015

@vshab Regarding the first issue, etags are never returned on the first request, as a performance oriented implementation detail, and works as expected. You are very welcome to submit updated documentation to hapi that explains this.

Regarding the others, please report it here: https://github.com/hapijs/inert/issues.

@vshab
Copy link
Author

@vshab vshab commented Jul 4, 2015

@hueniverse Thank you for quick response! Ok, I'll do it.

@vshab I was thinking about it but provided the info here may be to see the whole picture. I will open the issue in inert and take a look at documention.

@kanongil
Copy link
Contributor

@kanongil kanongil commented Jul 4, 2015

I had another look at the second case, and as far as I can tell, this is a hapi issue. Since content-encoding is not set on 304 responses (_isPayloadSupported() === false), the subsequent vary check to add the -gzip designator is never performed.

I can fix the issue but I doubt my solution is suitable, and I hope that @hueniverse will have time to look into it.

@hueniverse hueniverse reopened this Jul 4, 2015
@hueniverse hueniverse added bug and removed dependency labels Jul 4, 2015
@kanongil
Copy link
Contributor

@kanongil kanongil commented Jul 4, 2015

The final case actually works as expected until the last point, where it uses the sha1 sum of an empty file. I have created hapijs/inert#27 to track this.

@atomantic
Copy link

@atomantic atomantic commented Aug 3, 2015

Not sure if this is an inert issue or Hapi/inert integration issue, but it looks like Hapi.js sends "cache-control: no-cache" with a 304 instead of sending the cache-control that would be sent with a 200. Is this a known issue? A choice? It doesn't match this RFC: https://tools.ietf.org/html/rfc7232#section-4.1

The server generating a 304 response MUST generate any of the following 
header fields that would have been sent in a 200 (OK) response 
to the same request: 
Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

I could open this as another issue if it's warranted.

@kanongil
Copy link
Contributor

@kanongil kanongil commented Aug 3, 2015

@atomantic Seems valid. Please open a new issue.

hueniverse pushed a commit that referenced this issue Aug 7, 2015
@hueniverse hueniverse added this to the 9.0.0 milestone Aug 7, 2015
@hueniverse hueniverse closed this in 74cf80b Aug 7, 2015
@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Aug 7, 2015

@kanongil @atomantic can you please look at fix and make sure all of the issues listed in here have been addressed between hapi and inert changes?

@lock lock bot locked as resolved and limited conversation to collaborators Jan 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants