Hey David, thanks for your answer. I took a look again and: yes - all response headers reach the browser as expected.
Today I switched our production setup back from ``xsiframe`` to ``xs`` linker which solves the issue. This seems to be a good solution as ``xsiframe`` is only necessary for development imho. Moreover a collegue in my team told me there is a bug with ``xsiframe`` and ipad currently. Questions: * Should I report a bug for ``xsiframe``? * What about ``xsiframe`` - will this be the "next generation" ``xs`` linker? * whats the reason for appending ``serial=0`` to the splitted js files when using ``xs`` linker? http://beta/latest/vz_main/deferredjs/27FDB52EE40059691D73F91CDA95778F/12.cache.js?serial=0 Cheers, Andi On 1 Jun., 14:26, David Chandler <[email protected]> wrote: > Hi Andi, > > Have a look at the browser's Developer Tools to inspect what the browser is > actually seeing. In the initial response from the server, do the > Last-Modified, Expires, and Cache-control headers appear as above? In the > subsequent request, is the browser sending an If-Modified-Since header based > on the Last-Modified time as above? > > /dmc > > > > > > > > > > On Wed, Jun 1, 2011 at 6:11 AM, pansen <[email protected]> wrote: > > Hey guys, > > > it seems not as if this is a gwt issue, but a header/browser issue. > > I'm asking you anyway, maybe someone knows about the way splitted > > scripts are requested. > > > I proved the server responds in a correct manner if ``If-Modified- > > Since`` is sent. > > > # this file is included in the hosted page via ``<script>`` tag. and > > will respond a 304 the second > > # time i load the page > > [andi]$ curl -is > >http://dev.beta/latest/vz_main/ADF0D4E5642BF488EE5572F64496EB0A.cache...head > > HTTP/1.1 200 OK > > Server: nginx > > Date: Wed, 01 Jun 2011 09:50:08 GMT > > Content-Type: application/x-javascript > > Connection: keep-alive > > Vary: Accept-Encoding > > Content-Length: 569494 > > Last-Modified: Tue, 31 May 2011 13:07:42 GMT > > Expires: Fri, 01 Jul 2011 09:50:08 GMT > > Cache-Control: max-age=2592000 > > [andi]$ curl -is > >http://dev.beta/latest/vz_main/ADF0D4E5642BF488EE5572F64496EB0A.cache.js > > -H 'If-Modified-Since: Tue, 31 May 2011 13:07:42 GMT'|head > > HTTP/1.1 304 Not Modified > > Server: nginx > > Date: Wed, 01 Jun 2011 09:52:17 GMT > > Connection: keep-alive > > Last-Modified: Tue, 31 May 2011 13:07:42 GMT > > Expires: Fri, 01 Jul 2011 09:52:17 GMT > > Cache-Control: max-age=2592000 > > Access-Control-Allow-Origin:http://xss.beta:9667 > > > # this file is one of the splitted ones and will always get fully > > loaded > > [andi]$ curl -is > >http://dev.beta/latest/vz_main/deferredjs/ADF0D4E5642BF488EE5572F6449...head > > HTTP/1.1 200 OK > > Server: nginx > > Date: Wed, 01 Jun 2011 09:52:59 GMT > > Content-Type: application/x-javascript > > Connection: keep-alive > > Vary: Accept-Encoding > > Content-Length: 173765 > > Last-Modified: Tue, 31 May 2011 13:07:42 GMT > > Expires: Fri, 01 Jul 2011 09:52:59 GMT > > Cache-Control: max-age=2592000 > > [andi]$ curl -is > >http://dev.beta/latest/vz_main/deferredjs/ADF0D4E5642BF488EE5572F6449... > > -H 'If-Modified-Since: Tue, 31 May 2011 13:07:42 GMT'|head > > HTTP/1.1 304 Not Modified > > Server: nginx > > Date: Wed, 01 Jun 2011 09:53:40 GMT > > Connection: keep-alive > > Last-Modified: Tue, 31 May 2011 13:07:42 GMT > > Expires: Fri, 01 Jul 2011 09:53:40 GMT > > Cache-Control: max-age=2592000 > > Access-Control-Allow-Origin:http://xss.beta:9667 > > > You can see there is no server configuration issue as far as i can > > see. I just set the nginx ``expires`` directive to ``30d`` > >http://wiki.nginx.org/HttpHeadersModule#expires > > > Anyone knows how to tweak the response headers to a browser to cache > > these files? > > > Cheers, Andi > > > On 30 Mai, 17:52, pansen <[email protected]> wrote: > > > Hey, > > > > we are successfully using the codesplitting feature in our project. on > > > our staging server, i recognized that all splitted files are always > > > completely loaded from the server. All files included in the hostpage, > > > will send a ``If-Modified-Since`` header the second time I load the > > > app:: > > > > If-Modified-Since Mon, 30 May 2011 14:29:42 GMT > > > Cache-Control max-age=0 > > > > All splitted JS files are correctly loaded afterwards, but the problem > > > is they never contain these information (``If-Modified-Since`` > > > header). So the server is not able to respond with a 304 Not > > > Modified. > > > > Can someone give me a hint where to tweak this behaviour? > > > > The advice given here: > >http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideCompi... > > > also wont work without that header. > > > > Thanks, Andi > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > David Chandler > Developer Programs Engineer, Google Web Toolkit > w:http://code.google.com/ > b:http://googlewebtoolkit.blogspot.com/ > t: @googledevtools -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
