I think this strategy seems good, and easy. I'll implement it if no one
objects. I'd keep xmlInput and dictInput, but they would just be
implemented as self.request().fieldStorage().file.read()
I also think we should change text/python/pickled/dict to
text/x-python-pickled-dict, which is the valid way to construct new MIME
types (which aren't hierarchical). We can still accept the old MIME
type. OTOH, I'm not even sure where we'll look at it (since both XMLRPC
and Pickled servlets are intrinsic to the servlet itself).
On Tue, 2002-06-04 at 16:31, Chris Prinos wrote:
> > 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
>
|