[Pharo-project] Zinc Post requests
Hi Sven, Does #requestBodyFor: in the Zinc server adaptor for Seaside work? Instead of a String I keep on getting strange things back :-) Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas, On 20 Nov 2011, at 18:45, Lukas Renggli wrote:
Hi Sven,
Does #requestBodyFor: in the Zinc server adaptor for Seaside work?
Instead of a String I keep on getting strange things back :-)
Given the current implementation: requestBodyFor: aZincRequest ^ aZincRequest entity you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect. As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. The #contents method does try to return something useful (sometimes higher level Smalltalk objects). BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? Summary: if you known what should be passed in the different cases, I might be able to tell you how to get to it. Sven PS: which Seaside tests touch this ?
Given the current implementation:
requestBodyFor: aZincRequest ^ aZincRequest entity
you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect.
As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted.
Seaside expects a string containing the byte representation of what got posted.
The #contents method does try to return something useful (sometimes higher level Smalltalk objects).
BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ?
Have a look at the Kom adaptor: requestFieldsFor: aNativeRequest | fields | fields := WARequestFields new. aNativeRequest isPostRequest ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. ^ fields requestBodyFor: aNativeRequest ^ aNativeRequest rawRequestContents Lukas
Well I guess this would then do the trick: requestBodyFor: aZincRequest ^ String streamContents: [ :stream | aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. Should I try to write a version and commit it ? Sven On 20 Nov 2011, at 20:35, Lukas Renggli wrote:
Given the current implementation:
requestBodyFor: aZincRequest ^ aZincRequest entity
you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect.
As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted.
Seaside expects a string containing the byte representation of what got posted.
The #contents method does try to return something useful (sometimes higher level Smalltalk objects).
BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ?
Have a look at the Kom adaptor:
requestFieldsFor: aNativeRequest | fields | fields := WARequestFields new. aNativeRequest isPostRequest ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. ^ fields
requestBodyFor: aNativeRequest ^ aNativeRequest rawRequestContents
Lukas
On 20 November 2011 22:07, Sven Van Caekenberghe <sven@beta9.be> wrote:
Well I guess this would then do the trick:
requestBodyFor: aZincRequest     ^ String streamContents: [ :stream |         aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ]
but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient.
Should I try to write a version and commit it ?
Yes please, because the current Zinc does not work otherwise for POST requests. I understand the current behavior of Seaside is not ideal and it is cool that Zinc is more powerful than what Seaside expects, but then we have to find a way to expose that in compatible way. Lukas
Sven
On 20 Nov 2011, at 20:35, Lukas Renggli wrote:
Given the current implementation:
requestBodyFor: aZincRequest    ^ aZincRequest entity
you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect.
As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted.
Seaside expects a string containing the byte representation of what got posted.
The #contents method does try to return something useful (sometimes higher level Smalltalk objects).
BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ?
Have a look at the Kom adaptor:
requestFieldsFor: aNativeRequest    | fields |    fields := WARequestFields new.    aNativeRequest isPostRequest        ifTrue: [ self postFieldsOf: aNativeRequest into: fields ].    ^ fields
requestBodyFor: aNativeRequest    ^ aNativeRequest rawRequestContents
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On 20 Nov 2011, at 22:30, Lukas Renggli wrote:
Yes please, because the current Zinc does not work otherwise for POST requests.
Name: Zinc-Seaside-SvenVanCaekenberghe.21 Author: SvenVanCaekenberghe Time: 20 November 2011, 10:55:28 pm UUID: 2d3dd79e-7210-4e42-ba85-b08e6f74b689 Ancestors: Zinc-Seaside-SvenVanCaekenberghe.20 added a new implementation of ZnZincServerAdaptor>>#requestBodyFor: this idea is that we have to return a String that contains the raw entity bytes. we don't do this when #requestFieldsFor: returns that data in an other form (i.e. when it is a POST with application/x-www-form-urlencoded or multipart/form-data). still this is inefficient for ZnStringEntity objects with a non-trivial encoding since they will be reencoded after just being decoded.
participants (2)
-
Lukas Renggli -
Sven Van Caekenberghe