[Web-SIG] Request/Response features

[David Fraser]

Ian Bicking wrote:

> On Wednesday, October 22, 2003, at 10:12 PM, Ian Bicking wrote:
>
>> I've very interested into getting some sort of sane request/response 
>> object into the Python standard library, to form the basis of an 
>> informal standard on how those objects should look (even if wrappers 
>> or adaptation are required for most frameworks).  Technically I 
>> suppose cgi.FieldStorage is a request object, but it's not a very 
>> good one, and it's very incomplete outside of CGI (e.g., output goes 
>> to sys.stdout, headers come from os.environ), and unusable in a 
>> threaded environment.
>
>
> I should actually append to this, on the pyweb list (archives at 
> http://www.amk.ca/pipermail/pyweb/ ) I proposed a request/response 
> interface, as a discussion starter if nothing else.  Well, 
> constructive discussion didn't actually ensue, but the spec still 
> exists.  In retrospect I shouldn't have tried to include anything 
> outside of the request and response, as it's distracting and more 
> controversial.  The interface I wrote is at:
>
>   http://colorstudy.com/~ianb/IHTTP_01.py
>
> If rewriting it, I'd probably just put the response in the request 
> instead of having a transaction object -- the interface would consist 
> purely of HTTPRequest and HTTPResponse.  I might remove some other 
> methods as well, to make adapting/wrapping from other frameworks 
> easier.  Anyway, it could serve as a starting point for other 
> interface specifications. 

Hi

Had a look at this, it's nice for a start. However I agree with you that 
the transaction interface is confusing... for example, what does 
"setTransaction" mean/do?
Some other comments:
pathInfo/requestURI
  would be good to have some consistency between these names
getFields
  I don't think the ordering is generally important to people, so why 
not ignore it, because if people want to preserve it, they can always 
write some code to do that, but it's hardly needed as default functionality.
getFieldDict
  It would be great if the user could set the behaviour they want for 
multiple keys.
  I know I *always* want to discard any extra values. Including an 
option to do this rather than return a list would prevent lots of people 
doing post-processing

General comment here: there are quite a few different methods to handle 
getting/setting get/post fields. Perhaps this would be made simpler by 
using a standard dictionary interface. That would also clear up 
confusion about what parameters to pass to setFieldDict etc. Another 
question is whether people really need get and post arguments to be 
processed differently.

Also, is it neccessary for all attributes to be accessed by methods? 
Particularly (no pun intented) things like "method", "time" would seem 
to make more sense as attributes. If anyone really needs to run some 
code to access them,

The input method seems strange. Perhaps this should be called read? In 
general, there needs to be a clear separation between low-level 
accessing of the request stream, and higher-level accessing of processed 
get/post fields. Perhaps a way to do this would be to analyse how the 
most popular existing servers do things, then define a set of low-level 
methods which would cover their functionality. If this was done well, 
the higher-level methods could be written so that they always fall back 
to use the underlying low-level methods if they aren't overridden, so at 
least people only have to implement basic functionality to match the API.

Anyway those are just a few thoughts.

David