Jeanfrancois Arcand wrote:
> Salut,
>
> Vivek Pandey wrote:
>> I use GlassFish v3 kernel/grizzly inside GlassFish gem. There is
>> issue dealing with Grizzly caching behavior. One of my user reports
>> that HTTP caching is not working.
>
> For the last year File Caching was broken on v3.
>
> For each of the cached resources in the browser,
>> where an Apache or Mongrel server will send right caching headers and
>> ETag so that the client side cache can use it so that server can send
>> 304 (not modified). GlassFish v3 server/Grizzly always sends 200 OK
>> with the static resource.
>
> Right. That's because you are using the StaticResourceAdapter, which
> doesn't support 304
>
and neither does file-cache, right?
>>
>> Is HTTP cache control behavior support in the file-cache feature?
>
> No.
>
Problem is, unlike servlet container (which does take care of http
caching behavior), I depend on grizzly. It can be done in my module but
then it defeats the purpose as you really expect the low level http
listeners to pretty much deal with it.
> I just
>> checked out the code and dont think its fully supported. For example
>> there can be a case where a client can send ETag and
>> If-modified-since header, to which the server can send 304 indicating
>> the cache is still fresh. Maybe I missed something but can someone
>> confirm if full HTTP caching is going to be supported?
>
> It may work once we integrate 1.9.18, but the behavior you are asking
> will not, e.g Grizzly will always return 200.
This behavior is defined in HTTP 1.1 spec. IOW, looks like Grizzly
file-caching behavior is not HTTP 1.1 compliant. This is a clear bug.
> The Etag/if-modified-size are derived from the domain.xml configuration.
>
I thought ETag is generated as a unique identifier by the web server for
each of the static resource asked. As mentioned in the HTTP 1.1 spec, it
could be resource URL + timestamp MD5 value or something like that.
If-modified-since HTTP header is sent by the client(browser) to check
for freshness.
>>
>> Also, Ruby support is achieved thru a implementation of
>> GrizzlyAdapter. Jeanfrancois indicated file-cache is going to work
>> with it.
>
> Ya sometimes I say some strange things :-)
>
and I doubted that as well :-)
> I still am
>> not sure, how do I indicate Grizzly where the static resources are
>> kept? Will my current code work with it:
>>
>> this.setHandleStaticResources(true);
>> this.setRootFolder(config.appRoot() + File.separator+"public");
>>
>>
>> If not then how to I tell Grizzly where to serve the files?
>
> I think we need more work to make it work with JRuby. Invoking the
> above will now works as right now we do some special processing for
> the WebContainer, and by default we cache file located under:
>
>> String docroot =
>> System.getProperty("com.sun.aas.instanceRoot")
>> + File.separatorChar + "applications";
>> String uri = req.requestURI().toString();
>
> which represent the location of the exploded war file. Does JRuby
> application when deployed goes under that directory as well?
No. Ruby applications are deployed as directory so they are not copied
inside domain. This shoud be configurable using docroot configuration
inside domain.xml. If the docroot value received from domain.xml is null
then only the above code should come in to play.
> In any case, file an issue in GlassFish as I doubt it will works right
> now.
>
I will.
thanks,
-vivek.
> A+
>
> --Jeanfrancois
>
>
>
>>
>> -vivek.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>