[Solved] [BUG] FileETag Directive in HTACCESS

Discussion in 'Bug Reports' started by kellogg9, May 8, 2017.

  1. kellogg9

    kellogg9 New Member

    Seems there is a bug in the FileEtag directive. Here is a test to show what i mean.

    The test files will be:

    PNG Image file : test.png
    CSS Stylesheet file : test.css

    Now, with an empty .htaccess file the response headers are as follows (take note of the ETag header for each file):

    Response: test.png

    Etag: "64076-59091ddd-a998062746762090"
    Accept-Ranges: bytes
    Cache-Control: public, max-age=604800
    Connection: Keep-Alive
    Content-Length: 409718
    Content-Type: image/png
    Date: Mon, 08 May 2017 16:25:04 GMT
    Expires: Mon, 15 May 2017 16:25:04 GMT
    Last-Modified: Wed, 03 May 2017 00:01:33 GMT
    Server: LiteSpeed

    Response: test.css

    Etag: "4b-591098b8-3b36b002c17673a0"
    Accept-Ranges: bytes
    Cache-Control: public, max-age=604800
    Connection: Keep-Alive
    Content-Length: 75
    Content-Type: text/css
    Date: Mon, 08 May 2017 16:19:50 GMT
    Expires: Mon, 15 May 2017 16:19:50 GMT
    Last-Modified: Mon, 08 May 2017 16:11:36 GMT
    Server: LiteSpeed

    Everything looks good.

    Results
    Etag for test.png : 64076-59091ddd-a998062746762090
    Etag for test.css : 4b-591098b8-3b36b002c17673a0

    On my server Etags by default are output in a 3-component display made up of encoded versions of: <File's Size> -<File's Modified Time> -<INode> in that order.

    Now, let's modify our empty .htaccess file to include these lines only:

    <FilesMatch "\.(gif|jpg|png|css)$">
    FileETag MTime Size
    </FilesMatch>

    Take note of the FileETag directive. This tells the server to modify the ETag output header to use only 2-components instead of all 3. More specifically, it says to output the ETag header to use only the <File's Size> -<File's Modified Time> , and exclude the <INode> component. So, if its functioning correctly the output for both should be:

    Etag for test.png : 64076-59091ddd
    Etag for test.css : 4b-591098b8

    So, let's re-run our tests and see what we get.

    Response: test.png:

    Etag: "64076-59091ddd-0"
    Accept-Ranges: bytes
    Cache-Control: public, max-age=604800
    Connection: Keep-Alive
    Content-Length: 409718
    Content-Type: image/png
    Date: Mon, 08 May 2017 16:12:27 GMT
    Expires: Mon, 15 May 2017 16:12:27 GMT
    Last-Modified: Wed, 03 May 2017 00:01:33 GMT
    Server: LiteSpeed

    Response: test.css:

    Etag: "4b-591098b8-0"
    Accept-Ranges: bytes
    Cache-Control: public, max-age=604800
    Connection: Keep-Alive
    Content-Length: 75
    Content-Type: text/css
    Date: Mon, 08 May 2017 16:21:11 GMT
    Expires: Mon, 15 May 2017 16:21:11 GMT
    Last-Modified: Mon, 08 May 2017 16:11:36 GMT
    Server: LiteSpeed

    Hmmm..something looks wrong.

    Results
    Etag for test.png : 64076-59091ddd-0
    Etag for test.css : 4b-591098b8-0

    Notice how instead of getting just 2 components we are still getting 3 but worse is the 3rd component (the <INode> part) is now outputting as "-0 " instead of just being excluded (dropped) entirely.

    So it seems this is not a problem caused by me or using things like Wordpress since my htaccess file is bypassing them entirely. It seems LiteSpeed has a bug with ETags if someone attempts to make use of the FileETag directive in their htaccess file. I'd love to be wrong about this but it seems to point to the server software.

    Playing further if you modify the FileEtag directive to say use only 1 component such as MTime only the output will be in the format: "0-<File's Modified Time>-0 "...it now includes two "-0 " parts instead of dropping them, which is even more wrong.

    Now, if you modify the FileEtag to include all 3 components ie. FileETag MTime Size INode then the output is correct, and the result is just like the default process of showing all 3 components (as if my htaccess was empty).
     
  2. mistwang

    mistwang LiteSpeed Staff

    it is as designed, if you turn one component off, it will be "0", instead of complete remove it. Etag to identify if a object has been changed due to Etag change, whether put "-0" there or not does not affect the end result in anyway.
     
  3. kellogg9

    kellogg9 New Member

    Ahhhh...seems to be different than how Apache did things. When i do the same for Apache server they remove the "-0" part.

    I posted beacuse the issue results in YSlow website tests by those who use it e.g. GMetrics, Google saying "Etags are Misconfigured" because of the "-0" part...i figure YSlow test results just don't like the "-0". I assume there is no way at all to turn off this by-design choice and i just have to look by these misconfigured result reports by YSlow and others?

    Thanks for the clarification.
     
  4. mistwang

    mistwang LiteSpeed Staff

    We could update our code to do it in a way similar to Apache, if it is causing trouble on YSlow score.
     
  5. JohnDavidson

    JohnDavidson New Member

    I am having the exact same issue! Gmetrix is telling me my etags are misconfigured. When using FileETag MTime Size I get the same -0 component.
    I thought something was wrong and have been struggling to fix it without success for the past few days then found this post. Looks like it is working correctly then.
    The only issue is my assets don't seem to be returning a 304 response on repeated views unless i'm testing this incorrectly. Is there a way i can verify the etag is working correctly?
     
  6. mistwang

    mistwang LiteSpeed Staff

    Please upgrade to latest build of 5.2 see if the problem is fix or not.
    /usr/local/lsws/admin/misc/lsup.sh -f -v 5.2
     
  7. JohnDavidson

    JohnDavidson New Member

    Hi Mistwang,
    It took a while before my host was able to upgrade litespeed to 5.2 as they needed to test it out first before rolling out the update.
    My server has been updated now, and i no longer have the issue with etags. So looks like the update did the trick! Thanks
     
    Michael A likes this.

Share This Page