+1 to allowing the http method to be set/overwritten in a request parameter

Michael

On 12/18/07, Lars Trieloff <[EMAIL PROTECTED]> wrote:
>
> Mindquarry has a filter that covers the first part, so ?http-X-HTTP-
> Method-header=PUT would be changed to the corresponding header (our
> pattern is http-(.*)-header), so all you have to do is adding a hidden
> field like
>
> <input name="http-X-HTTP-Method-header" value="PUT"> to your form. An
> even more easy to use solution would be the introduction of a
> <sling:form> JSP tag, that would insert this hidden field
> automatically for if the method of the form was not GET or POST.
>
> regards,
>
> Lars
>
> On 18.12.2007, at 13:09, Felix Meschberger wrote:
>
> > Am Dienstag, den 18.12.2007, 12:40 +0100 schrieb Lars Trieloff:
> >> At least with µjax we have more control over the client than with
> >> standard web forms, and even then, a concatenation of two
> >> ServletFilters* and a hidden field could make a POST request into a
> >> PUT request. So the server-side development can clearly separate the
> >> concepts.
> >>
> >> * ServletFilters: 1st changes Request-Parameters with a certain
> >> naming
> >> pattern into request headers. This overcomes the disability of web
> >> browsers to set headers programatically.
> >> 2nd uses a header like X-HTTP-Method to override the HTTP method.
> >
> > Sounds like proper separation of concern. For maximum ease of use, I
> > would assume the same names acceptable for the parameters in the first
> > filter as are used for the request header in the second filter.
> >
> > Regards
> > Felix
> >
> >>
> >> Lars
> >>
> >> On 17.12.2007, at 23:03, Felix Meschberger wrote:
> >>
> >>> Am Freitag, den 14.12.2007, 19:59 +0100 schrieb Tobias Bocanegra:
> >>>>> Why not use something like custom headers like X-HTTP-Method and a
> >>>>> servlet filter to wrap PUTs in POSTs?
> >>>>>
> >>>>> As we control the client API, this is a cleaner way to do this
> >>>>> IMHO.
> >>>>
> >>>> but we do not control the client. the goal is to use simple html
> >>>> forms...
> >>>
> >>> That is only partly true of course: We define a protocol to use when
> >>> sending data or requesting content to be stored or created. So, if
> >>> we
> >>> require a specific parameter (agreed, that headers more involved and
> >>> won't work with simple forms), it is just part of the protocol...
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> [EMAIL PROTECTED]
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> [EMAIL PROTECTED]
> http://weblogs.goshaky.com/weblogs/lars
>
>


-- 
Michael Marth, http://dev.day.com

Reply via email to