I don't see the need to keep xmlInput and dictInput -- in fact, it'll be cleaner if they disappear. They are only used by the respective XMLRPCServlet and PickleRPCServlet, both of which could be changed to do the right thing.
Maybe a more general .input() method? (Not sure if that name is already taken.) - Geoff > -----Original Message----- > From: Ian Bicking [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 5:11 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Webware-devel] RE: [Webware-discuss] Content-type > handling in > HTTPRequest > > > 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 > > > > > > _______________________________________________________________ > > 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-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-devel > _______________________________________________________________ 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
