Matches the WebDAV/Windows front: Microsoft's WebDAV client do send wrong
Accept headers. While WebDAV enforces a particular one (so one would write a
JAX-RS resource matching that one), Microsoft is sending a different one. I
you don't want to workaround in your JAX-RS resource, you can keep a "clean"
WebDAV JAX-RS implementation by rewriting Accept: headers in a pre-match
filter as soon as you detect that header plus a Microsoft-Agent header.
Which is in fact, what our filter does (and much other things). So we
definitively need it.
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Montag, 14. November 2011 18:58
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal for
> Pre-Match Filters
>
>
> On Nov 14, 2011, at 9:34 AM, Santiago Pericas-Geertsen wrote:
>
> > On Nov 11, 2011, at 7:08 PM, Bill Burke wrote:
> >
> >> What is the usecase for a pre-match filter? It just seems there's
> very little you can do before you know what resource(class/method) the
> http request is bound to.
> >
> > Essentially anything that updates the input to the matching
> algorithm. The canonical example is a filter that overrides the HTTP
> method, e.g. using X-HTTP-Method-Override (quite popular given that a
> lot of routers drop non-GET/POST requests).
>
> Another example I recently came across is patching some ugly Accept
> headers generated by certain tools. Even with support for the qs
> parameter during matching, it was impossible to get the desired
> behavior without patching that header.
>
> -- Santiago
>