cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Juffer <andre.juf...@oulu.fi>
Subject Re: Cocoon 2.2 PUT HTTP request
Date Tue, 21 Sep 2010 13:59:29 GMT
Thanks for your response.

I am going to try this and see if this works. The RequestMethodSelector 
is also available in Cocoon 2.2. I just did not expect that one must use 
it to identify the request method in the sitemap, given that the request 
object is available as cocoon.request in flow as well.


On 09/21/2010 04:40 PM, florent andré wrote:
> Hi Andre,
>
> Thanks for your day to day research feedback.
>
> In Lenya (widely use of cocoon), we have this :
> <map:select type="request-method">
> <!-- many client editors like to PUT changes -->
> <map:when test="PUT">
> <map:mount uri-prefix="" 
> src="{fallback:lenya/modules/webdav/sitemap.xmap}" check-reload="true" 
> reload-method="synchron"/>
> </map:when>
> </map:select>
>
> So the request-method selector seems to detect PUT.
>
> The selector is implemented here : 
> cocoon_2_1_x/src/java/org/apache/cocoon/selection/RequestMethodSelector.java 
>
>
> With this code :
> String method = ObjectModelHelper.getRequest(objectModel).getMethod();
>
> Note that is cocoon 2.1, but normaly no big changes with 2.2.
>
> Maybe selector and input don't have the same implementation ?
>
> Just some piece of informations I have. I'm not enough inform about 
> how cocoon deal with request for helping more.
> HTH
>
> ++
>
>
> On 09/21/2010 03:10 PM, Andre Juffer wrote:
>> Dear All,
>>
>> in a previous thread, I was trying to understand why I could not see the
>> request parameters of a HTTP PUT request using the
>> cocoon.request.getParameter("...") family of methods in flowscript.
>> Conclusion: For a PUT request, according to specification, the servlet
>> engine is -not- required to parse the request for making the parameters
>> available through request.getParameter("..") and consequently also
>> cocoon.request.getParameter("...") will not return a value (just
>> 'null'). [1]
>>
>> One remedy is assume POST requests (client side) instead for the time
>> being, despite differences in the meaning of POST and PUT with regard to
>> RESTful applications.
>>
>> There is still one other issue to be solved. In the case of a PUT
>> request (or any other HTTP request for that matter), my understanding is
>> that I should be able to identify the request HTTP method in flowscript
>> by cocoon.request.getMethod() or in a pipeline using <map:parameter
>> name="method" value="{request:method}" />. I find in either case that
>> this parameter's value is always GET, whatever the original request
>> method received by the servlet engine was. It seems that the original
>> request method value is simply lost somewhere, -before- the request is
>> being handled in the sitemap.
>>
>> I now seek answers to the following:
>>
>> 1. Can one of you confirm (or not) that this is indeed the case. That
>> is, cocoon interferes with the original request and makes it a (or
>> creates a new) GET request. It is certain that the servlet engine
>> receives the PUT request in good order. It is also certain that the
>> servlet engine is not changing the original request. It simply passes it
>> on the cocoon-based webapp.
>>
>> 2. If item 1 above is in fact true (and I really hope this is not the
>> case), what would be solution to overcome this issue. I could image
>> making a filter that adds an extra parameter or attribute
>> 'request-method' or something to the request that retains the original
>> HTTP method and query for its value in the sitemap or in flowscript. I
>> have to hope that cocoon retains this extra parameter or attribute when
>> it receives the request.
>>
>> I would very much appreciate any response in this matter. I could not
>> find answers on the cocoon email lists or in the documentation,
>> unfortunately.
>>
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/cocoon-users/201009.mbox/browser 
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


-- 
Andre H. Juffer              | Phone: +358-8-553 1161
Biocenter Oulu and           | Fax: +358-8-553-1141
Department of Biochemistry   | Email: andre.juffer@oulu.fi
University of Oulu, Finland  | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat                   | WWW: www.strubiocat.oulu.fi
NordProt                     | WWW: www.nordprot.org
Triacle Biocomputing         | WWW: www.triacle-bc.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message