Salut,
Vivek Pandey wrote:
> 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?
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.
That's *not* true. WebContainer does use Grizzly File Cache and doesn't
implement its own.
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'm not sure I agree. Other GrizzlyAdapter in V3 already implemented
their solution (look at the WebStart Adapter). I think a generic file
cache that support all kind of Adapter is something not needed IMO.
There is way to many possibility in v3, way to many places where files
are located to be able to support them from Grizzly standalone. This
need to be implemented on the v3 side, probably as an extension to
GrizzlyAdapter.
>
>> 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.
Can you pint me to the link?
>
>> 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.
In v3 this is generated by the appropriate Adapter. Right now the
WebContainer generates it when deployed. If not deployed, we don't add Etag.
>
>>>
>>> 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 :-)
Just to make sure we are on the same page. It will works in v3 but we
need to make sure the v3 *code* knows where the JRubyAdapter place the
static file. Based on this email I suspect we can derive that value from
the Adapter. So what I mean above is that it *will* works once we
properly implement it in v3.
A+
-- Jeanfrancois
>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>