Marc,
That's very reasonable, we can definitely leave this "tunnel" features (HTTP
method and Accept headers) to the container. In a Restlet component, we will
simply rely on the existing tunnel service. Perfect.
Best regards,
Jerome
> -----Message d'origine-----
> De : Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Envoyé : jeudi 26 avril 2007 19:32
> À : dev_at_jsr311.dev.java.net
> Objet : Re: Content Negotation vs. Extensions
>
> 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.
>
>
>