Hi all,
The interest of tunneling is mainly to allow limited browsers to issue
PUT/DELETE/MOVE/... calls directly from Web forms. In those cases it isn't
practical to rely on an extra HTTP header.
I would prefer a more automatic tunnel that would be turned off by default.
IMO, this is mostly an environment/deployment issue that shouldn't impact
the application design/resources.
Best regards,
Jerome
> -----Message d'origine-----
> De : Stefan Tilkov [mailto:stefan.tilkov_at_innoq.com]
> Envoyé : jeudi 26 avril 2007 19:23
> À : dev_at_jsr311.dev.java.net
> Objet : Re: PUT and DELETE tunneling
>
>
> On Apr 26, 2007, at 7:08 PM, Marc Hadley wrote:
>
> > On Apr 26, 2007, at 12:36 PM, Stefan Tilkov wrote:
> >
> >> Assuming my resource class is implemented "cleanly", i.e. it has
> >> post, put, delete and get methods (that map appropriately), this
> >> would mean I'd have to add another post method (like the one
> >> below) that calls delete(), and I'd have to do that for every
> >> resource. But in general, I will make the decision to use this
> >> workaround for my complete web app, not for each and every
> >> resource class. Can this be done in a generic way?
> >>
> >> I'm not at all sure I like this, but how about this,
> inspired by [1]:
> >>
> >> @HttpMethod(DELETE) @HttpMethodOverride("X-HTTP-Method-Override",
> >> PUT) void delete() {...}
> >>
> > In a servlet container you could just write a servlet filter to
> > patch the request method based on, e.g., the
> X-HTTP-Method-Override
> > header. That seems like a cleaner solution than us adding an
> > annotation to do the same sort of thing.
>
> OK - I agree that's a good approach.
>
> Stefan
>
> > Presumably other containers have similar capabilities ?
> >
> > Marc.
> >
> >>
> >> [1] http://code.google.com/apis/gdata/basics.html#Updating-an-entry
> >>
> >> On Apr 26, 2007, at 6:05 PM, Marc Hadley wrote:
> >>
> >>> On Apr 26, 2007, at 11:49 AM, Stefan Tilkov wrote:
> >>>
> >>>> I'm pretty sure there are strong opinions on this - just
> >>>> checking: do we want to support some way to do a pseudo-PUT and
> >>>> DELETE through POST?
> >>>> Even if we don't want to explicitly encourage it, do we want
> >>>> enable the API's users to do this? If so, how?
> >>>>
> >>> I think we already allow it using a variety of means but
> we don't
> >>> make it transparent. E.g. one could use a header or matrix URI
> >>> param to hold the put|delete method name and extract
> those in the
> >>> method:
> >>>
> >>> @HttpMethod(POST)
> >>> String doMethod(@HeaderParam("method") String method) {...}
> >>>
> >>> Is that good enough or do folks want something more automated ?
> >>>
> >>> Marc.
> >>>
> >>> ---
> >>> Marc Hadley <marc.hadley at sun.com>
> >>> CTO Office, Sun Microsystems.
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> 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.
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>