You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by pandareen <gi...@git.apache.org> on 2018/06/15 18:15:28 UTC

[GitHub] tomcat pull request #115: Setting Timezone to GMT for Expires Header as per ...

GitHub user pandareen opened a pull request:

    https://github.com/apache/tomcat/pull/115

    Setting Timezone to GMT for Expires Header as per RFC1123

    Tomcat response header 'Expires' is getting formatted into timezone based string and not just 'GMT' as specified under RFC 1123.
    
    I was facing issues with cache reload for my webapp specifically in Chrome and found out the response headers were like Cache-Control:private and Expires:Thu, 01 Jan 1970 05:30:00 IST
    
    I searched for few threads and found browsers only understand GMT.
    
    I've used the same code and format as used for setting Last-Modified as per the tomcat source code.
    


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/pandareen/tomcat trunk

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/tomcat/pull/115.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #115
    
----
commit a7d99a31d09fa2c398e5d640291e817b45f3c23f
Author: sandesh <sa...@...>
Date:   2018-06-15T17:53:43Z

    Committing changes to set GMT timezone on Expires header

----


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by pandareen <gi...@git.apache.org>.

Github user pandareen commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    Good thought @michael-o. I'll get some info from chromium...


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by pandareen <gi...@git.apache.org>.

Github user pandareen commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    @michael-o I built tomcat using `Expires` header as `0`, but chrome is still not understanding.....
    Here's a screenshot: [https://i.imgur.com/cSnuVIr.png](url)


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by michael-o <gi...@git.apache.org>.

Github user michael-o commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    The format is described here: https://tools.ietf.org/html/rfc7231#section-7.1.1.1
    Why not the stuff altogether and store the preformatted string in a static final? We can also use the value of `0` for expired stuff according to the RFC.
    
    @markt-asf 


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by rainerjung <gi...@git.apache.org>.

Github user rainerjung commented on the issue:

https://github.com/apache/tomcat/pull/115

@michael-o APR_DATE_BAD: the date string was null, or unparsable or the parsed date does not exist. A date in the past would not result in APR_DATE_BAD. A timestamp before the unix epoch should be fine as well, but I didn't check that. Concerning "Expires: 1970 ...[a valid formatted timestamp]" versus "Expires: 0" I might not understand your question. First "Expires: 0" is not valid, accoring to the HTTP RFC it is invalid, but the RFC defines how a client should behave when it notices such an invalid value. The RFC demands a formatted timestamp string as the value of the Expires header. Only such are valid due to the syntax of the header in RFC 7234:

Expires = HTTP-date
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>

and in RFC 7231

HTTP-date = IMF-fixdate / obs-date

and then lots of additional definitions making clear, that only formatted absolute timestamps in a few explicitly defined formats are allowed. Not allowed (invalid) are simple numerical offsets like "0".

BUT: RFC 7234 states that any invalid header must be handled like a vlid header with a timestamp in the past. My web server example shows, that not all products might interprete this sentence to the full extreme. Configuration options that for instance control the behavior of a shared cache in front of Tomcat might allow admins to overwrite caching decisions. In this case it could make a difference, whether the cache sees a valid Expires with a time in the past or an invalid one. As an example Apache httpd 2.4. I dont want to argue whether this is RFC compliant (because the config option operates explicitly outside of the RFC) and I hold the opinion, that the code of the cache should be changed to coincide more with that aspect of the RFC, but it was simply meant as an example why not relying too much on the RFC sentence, that an invalid Expires will be handled like on the past might lead to less runtime problems.

---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by michael-o <gi...@git.apache.org>.

Github user michael-o commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    @pandareen, how do you know that Chrome does not understand it?


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by michael-o <gi...@git.apache.org>.

Github user michael-o commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    @rainerjung My question simply was that if `Expires: 0` denotes a value in the past (expired already), why should I explicitly use a valid header in the past which requires more code to create as well as the bytes transported?


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by pandareen <gi...@git.apache.org>.

Github user pandareen commented on the issue:

https://github.com/apache/tomcat/pull/115

Okay let me explain.
Case 1. [https://i.imgur.com/tofjYaM.png](https://i.imgur.com/tofjYaM.png) - When chrome gets a `Cache-Control: no-cache` directive in response header, it sends `If-Modified-Since` and `If-None-Match` headers to the server to validate staleness in the next page request/reload. This makes perfect sense because if the resource is not changed in mean time, the server sends a 304 (not modified) status code and browser can use the same resource...

Case 2. [https://i.imgur.com/mOWglQL.png](https://i.imgur.com/mOWglQL.png) - When chrome gets a `Cache-Control: private` directive in response header, it is not sending the `If-Modified-Since` and `If-None-Match` in request headers and as a result you see the `Status Code: 200 OK (from memory cache)` which means chrome didn't try the server for the js file and loaded it again from the memory(But in reality I had made changes in js file). I tried to change/match headers like the no-cache case but couldn't get the headers going. Finally I noticed the `Expires` header doesn't have GMT in the string so I changed it and suddenly everything worked.

This lets me believe that in case 2, when chrome gets a `Cache-Control: private` directive, it requires a valid `Expires` header to trigger the cache validation request..

---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by rainerjung <gi...@git.apache.org>.

Github user rainerjung commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    @michael-o IMHO because an invalid header value will push most parsing code to the error handling code path. And only by additional rules should that code handle it like a valid header in the past. Your chances of client software compatibility are higher than by sending an invalid value. This of course is not an especially strong argument. I simply wanted to provide a real-world example, where it currently does make a difference.


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by rainerjung <gi...@git.apache.org>.

Github user rainerjung commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    Note that although the RFC demands to handle an invalid Expires header (like Expires: 0) like one with a timestamp in the past, I coincidentally ran into a problem yesterday, where the Apache web server with mod_cache only complies to this in the default case. By default in both cases content is not cached. But in the case of a valif timestamp in the past, more rules apply, like being able to force caching by configuration and also evaluating Cache-Control max-age and s-maxage. In the invalid Expires value case, the decision to not cache currently happens unconditionally.
    
    I applied a patch to the trunk of the Apache web server  yesterday and proposed it for 2.4, but it might serve as an example, why an explicit timestamp in the past might be slightly more robust (while being a bit more expensive) then just "Expires: 0" or any other invalid value.


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by michael-o <gi...@git.apache.org>.

Github user michael-o commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    Here is the reference commit: https://github.com/apache/httpd/commit/60087a708b051c3c987b80abdfdc3f2e046ebc4d
    
    @rainerjung How is `APR_DATE_BAD` defined? Unparsable? Or before Unix epoch? I still don't see how `Expires: 1970...` is better than `Expires: 0` when both are perfectly valid.


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[GitHub] tomcat issue #115: Setting Timezone to GMT for Expires Header as per RFC1123

Posted by michael-o <gi...@git.apache.org>.

Github user michael-o commented on the issue:

    https://github.com/apache/tomcat/pull/115
  
    Thanks for the explanation. I hardly believe that Chrome does not implement `Expires: 0`. At best, we inquire with the Chromium project.


---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org