Thanks. Done:
http://java.net/jira/browse/JERSEY-1189
In the meantime, what do people think of using a 204 in this case rather
than a 404? It would at least be cacheable.
sam
On Thu, May 31, 2012 at 3:15 PM, Pavel Bucek <pavel.bucek_at_oracle.com> wrote:
> That would be certainly possible and most likely correct way how we
> should handle that.
>
> Can you please file enhancement request?
> http://java.net/jira/browse/JERSEY
>
> (just copy&paste your last email).
>
> Thanks!
> Pavel
>
>
> On 5/31/12 8:54 PM, Sam Perman wrote:
>
> I'm not sure if this is the right mailing list for suggesting patches to
> jersey, but is this something that looks reasonable?
>
> WebComponent currently has code that looks like this:
>
> if (config.getConfigType() == WebConfig.ConfigType.FilterConfig
> &&
>
> resourceConfig.getFeature(ServletContainer.FEATURE_FILTER_FORWARD_ON_404)) {
> useSetStatusOn404 = true;
> }
>
> I'd like to be able to set this flag even if I'm not using a filter
> config (and I don't want to other behavior this flag causes). I was
> thinking of introducing a new feature and changing the code like so:
>
> if ((config.getConfigType() == WebConfig.ConfigType.FilterConfig
> &&
>
> resourceConfig.getFeature(ServletContainer.FEATURE_FILTER_FORWARD_ON_404))
> ||
> resourceConfig.getFeature(ServletContainer.FEATURE_USE_STATUS_ON_404) {
> useSetStatusOn404 = true;
> }
>
> thoughts?
> sam
>
>
> On Thu, May 31, 2012 at 10:35 AM, Sam Perman <sam_at_permans.com> wrote:
>
>> Unfortunately, a ContainerResponseFilter won't work because the call to
>> HttpServletResponse.sendError (see WebComponent line 278) happens after all
>> the filters have been invoked... meaning jetty will still replace my
>> Cache-Control headers.
>>
>> I'd like to be able to set "useSetStatusOn404" to true but I can't
>> figure out a way to actually do that (I'm using a servlet config, not a
>> filter config).
>>
>> sam
>>
>>
>> On Wed, May 30, 2012 at 4:29 AM, Pavel Bucek <pavel.bucek_at_oracle.com>wrote:
>>
>>> On 5/29/12 5:26 PM, Sam Perman wrote:
>>>
>>> It does look like its a jetty thing. We call Responses.notFound() which
>>> ultimately calls HttpServletResponse.sendError() which has the side effect
>>> of overriding the cache control header.
>>>
>>> if is the code which overrides cache control header in
>>> HttpServletResponse, it is generally "container thing" just because Jersey
>>> cannot really control what is done with the response after passing it to
>>> servlet container.
>>>
>>>
>>> Jetty has a way to configure this globally for all errors (
>>> http://jira.codehaus.org/browse/JETTY-1177 ) but we only really want to
>>> configure this for 404
>>>
>>> Is there a hook somewhere in jersey that would get called after we
>>> build our response but before we relinquish control back to jetty?
>>>
>>>
>>> ContainerResponseFilter for example. Or you can extend Jersey
>>> ServletContainer and control basically everything..
>>>
>>> Pavel
>>>
>>>
>>> thanks
>>> sam
>>>
>>> On Fri, May 25, 2012 at 5:30 PM, Sam Perman <sam_at_permans.com> wrote:
>>>
>>>> We're using jetty. I'll check that log to confirm.
>>>>
>>>> thanks
>>>> Sam
>>>>
>>>> On Friday, May 25, 2012 at 5:20 PM, Pavel Bucek wrote:
>>>>
>>>> I don't think this is added by Jersey, I usually tend to blame the
>>>> container for this. Which one are you using?
>>>>
>>>> You can also verify this statement by adding ContainerResponse
>>>> Logging
>>>> filter and check logs for that header, see
>>>>
>>>> http://jersey.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/package-summary.html
>>>>
>>>> Regards,
>>>> Pavel
>>>>
>>>> On 5/25/12 10:51 PM, Sam Perman wrote:
>>>>
>>>> Hi
>>>>
>>>> We want to be able to cache the 404 responses from our server no
>>>> matter what cache controls we set on the response, the headers that
>>>> are returned are always set to no cache (I think because
>>>> reseponse.sendError ultimately resets the cache control headers)
>>>>
>>>> Any ideas?
>>>>
>>>> thanks
>>>> sam
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>