[Seaside] Sending data through POST or PUT, with nginx

[Norbert Hartl]

Am 15.05.2012 um 01:22 schrieb Lawrence Kellogg:

> 
> On May 14, 2012, at 5:57 PM, Norbert Hartl wrote:
> 
>> 
>> Am 14.05.2012 um 21:45 schrieb Lawrence Kellogg:
>> 
>>> 
>>> On May 14, 2012, at 3:22 PM, Philippe Marschall wrote:
>>> 
>>>> On Mon, May 14, 2012 at 2:43 PM, Lawrence Kellogg <mac.hive at me.com> wrote:
>>>>> 
>>>>> On May 14, 2012, at 8:38 AM, Philippe Marschall wrote:
>>>>> 
>>>>>> On Mon, May 14, 2012 at 1:03 PM, Lawrence Kellogg <mac.hive at me.com> wrote:
>>>>>>> Hello,
>>>>>>> Do I need to do anything special to enable sending data for POST or PUT
>>>>>>> requests to a WARequestHandler in Seaside? Something in nginx.conf?
>>>>>>> GETs have been working fine for me.
>>>>>>> 
>>>>>>> My client app is sending a POST, with data, but nginx shows no
>>>>>>> data and the value in the dictionary fields shows nil for that entry.
>>>>>>> Perhaps the POST should be a PUT, but still, I don't get any data.
>>>>>>> 
>>>>>>> Also, is there some way to put a halt in a subclass of WARequestHandler
>>>>>>> so that I can get a continuation that I can debug? Halts just seem to
>>>>>>> throw a message to the log, but not pop up a continuation.
>>>>>> 
>>>>>> Can you provide a bit more context? Are you on GemStone with FastCGI?
>>>>>> 
>>>>> 
>>>>> Yes, I am on Gemstone using FastCGI.
>>>> 
>>>> Hmm, I can remember some posts (pun) from Norbert about this.
>>> 
>>> 
>>> ;-) This one: http://forum.world.st/About-Zinc-to-replace-HTTPClient-td3453621.html
>>> 
>>> ?
>>> 
>> :) Yes, it is a unfortunate postion at the moment. There is Kom, Swazoo and Hyper. Kom is really basic (and not existent in gemstone, but pharo). Swazoo and Hyper are more into "the real thing". But even swazoo and Hyper seriously lack support for most of the stuff. They support GET and also POST in a urlencoded fashion. That is everything seaside needs. If your needs are beyond that you're out of luck. To repeat my rant I would call it that they are overengineered for what they support working. There was good thinking in both of them as far as I can see but probably they are just unfinished. Zinc is different because it has full support for most things you really need. Zinc should be working in gemstone but I wasn't lucky to get it running reliably. Some more effort needs to be done. 
>> If you want to do POST then you should think if you can live with urlencoded data. That should work in any of the mentioned adaptors. Of course you want to just use the body but that's a no-go as far as I can tell.
>> I don't like the situation and I don't like my free time only leaves enough space to complain (instead of just fixing it) but anyhow we need to get zinc running on gemstone. In pharo the situation is just wonderful and I did newer projects in pharo instead of gemstone because of that (and SSL).
>> 
>> Sorry, for not being of any help here,
>> 
> 
> 
> Norbert, 
>  Thanks for your perspective. Well, we got it working this afternoon so that we could pass in a JSON string and parse it. 
> I was just a little confused with how to access the fields in the WARequest, but I finally figured it out. It's too bad that 
> putting a halt in the handleFIltered: method does not pop a continuation. Is there some way to make that happen? 
> Subclasses of WAComponent spin off a continuation when they hit a halt, 
> 
>  So, I think I have what I need to go forward, unless I'm missing something.
> 
Uhh, I need to roll back a bit. I shouldn't write mails when I'm coming from the Biergarten being extremely tired.:) Basically it is true what I said about the usability of most of the adaptors. But there is certainly more possible then I said. I'm using fastcgi on gemstone and I'm also using the body and multipart data for uploads.

The body I request via

self requestContext request bodyDecoded

and multipart files via

self requestContext request postFields at: aString

in the latter you need to check if you get a string or a WAFile. And you need to decode manually

Norbert