> Yes, this does appear to be a problem. There is some testing in
> FieldStorage as to the content-type, but if no content-type
> is given it
> assumes application/x-www-form-urlencoded. I assume this is because
> some clients do not set the content-type, and that this
> behavior should
> maintained for compatibility. I was looking at the FieldStorage code,
> and I couldn't quite figure out what happens when it gets a different
> content-type -- it seems to keep it somewhere (directly in
> .value of the
> FieldStorage instance?) If it does, I don't believe the Webware code
> will give access to it -- changing this would make xmlInput/dictInput
> unnecessary and probably be better all around.
>
I think I side tracked things a bit when I mentioned the part about clients
not setting the content-type, though is still relavant. The real issue is
that HTTPRequest.__init__ doesn't give you a chance to inspect the orginal
POST data. I thought this was odd at first, becuase cgi.FieldStorage lets
you get to the POST data (in fact it does it's own content type handling and
even tries to handle multi part)
I looked ath things some more, and about 2/3 of the way down the code in
HTTPRequest.__init__ (line 113 in the .7 release), there's the killer line:
self._fields = dict
This takes dict (the environment dictionary) and overwrites self._fields,
which to this point had been a FieldStorage.FieldStorage instance. The
intent is to make request().fields() just return a simple dictionary, but
once this is done you lose all the info that the FieldStorage object kept.
So if you replace line 113 with, for instance:
self._fieldStorage = self._fields
self._fields = dict
and to keep thing consistent add the method
def fieldStorage(self):
return self._fieldStorage
you can now access the POST data by doing the following from a servlet:
postData = self.request().fieldStorage().file.read()
similarly HTTPRequest's xmlInput() and dictInput() method could have just
returned self._fieldStorage.file without any of the current special case
code. Also unlike the limited file like object you get back from
socket.make_file, the fieldStorage().file object can be rewound with
seek(0).
> However, this doesn't solve your problem as you were talking about
> non-urlencoded input with no content-type to indicate that...
> if at all
> possible, I'd change these clients. text/xml will work (though be
> inaccurate), while text/plain seems more appropriate. To capture the
> input with no content-type, there'd have to be some setting
> to copy the
> input before it was sent to FieldStorage (it probably
> shouldn't do this
> by default, as it would consume more memory and web services *should*
> pass proper content-types, though that won't help you yet).
I think with the above changes, you get the benefits without the downside.
No copy is made (the FieldStorage instance has already been created), the
only difference is that you keep the reference to it around so you can use
it later
I'll play with this a bit and put in a bug report at the webware site.
Chris
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
