dev@jsr311.java.net

Re: Content Negotation vs. Extensions

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 26 Apr 2007 13:32:06 -0400

As suggested on the "PUT and DELETE tunneling" thread, when using a
Servlet container you could implement a servlet filter to patch the
Accept header value based on extension or query parameter value.

Marc.

On Apr 26, 2007, at 11:57 AM, Jerome Louvel wrote:

>
> Stefan,
>
>>> As serving files from directories on the file systems is
>>> not really in our scope,
>>
>> I don't recall suggesting it was ...
>
> I didn't mean to imply that. If mapping directories was indeed in
> our scope,
> we would have had to handle file extensions for sure. This was my only
> point.
>
>>> I think that when users need to specify a special media type that
>>> they want to get, they have two options:
>>>
>>> 1) Adjust their "Accept" header to force the conneg to return a
>>> specific
>>> representation
>>
>> I agree this is the clean way ...
>
> OK
>
>>> 2) Rely on a query parameter like "media=application/xml"
>>>
>>
>> ... while this seems to be just as good or bad as the other
>> suggestion.
>>
>>> Note that the ".xml" extension is more ambiguous than "application/
>>> xml" or
>>> "application/blinksale-xml".
>>>
>>
>> I agree.
>
> OK
>
>>> We could even automate the translation of the "media" parameter
>>> into an
>>> "Accept:" header like we do in the Restlet framework:
>>> http://www.restlet.org/documentation/1.0/api/org/restlet/service/
>>> TunnelServi
>>> ce.html
>>>
>>
>> Neat, but I'm not entirely sure I would like to go this far.
>> Enabling
>> people to build their own content negotiation replacement is one
>> thing, explicitly coding one into the framework is another - i.e. I
>> think we should enable common workarounds, but not encourage them.
>
> Such "tunnel" service could be turned off by default to not
> "encourage"
> relying on it.
>
> Best regards,
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.