[Web-SIG] Request/Response features

[Ian Bicking]

On Thursday, October 23, 2003, at 05:05 AM, David Fraser wrote:
>> The interface I wrote is at:
>>
>>   http://colorstudy.com/~ianb/IHTTP_01.py
 >
> 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 of the methods were for setting up the request, or modifying the 
request so it can be forwarded internally.  It might be fine to leave 
the request/response setup undefined -- it would be defined by the 
context, e.g., cgi would set it up one way, mod_python another, etc.  
For forwarding I think it might be better to simply create new object 
that would be reinjected into the framework.

> Some other comments:
> pathInfo/requestURI
>  would be good to have some consistency between these names

They are mostly based off their CGI environment equivalent.

> 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.

I agree, it should go.

> 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

That seems to difficult to define.  I don't think there should be 
customizations, because that makes it too difficult to work in a 
heterogeneous environment.  If you turn that setting on and some 
application you are using needs it off, then you get a configuration 
mess.  Wrappers could provide more friendly interfaces.

> 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.

People do need to access them separately, as that's a common feature 
request.  Usually they'd be accessing some combined version of those, 
but the option should be there.

> 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,

I wrote the interface with wrappers in mind, and I thought purely using 
methods would be easier and more explicit.

> 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.

I guess there's two ways you could go with that -- if a method is 
derivative of other methods, then just leave it out and let a wrapper 
implement it.  But that doesn't work particularly well if we want to 
use the request/response as part of the standard library (without any 
wrapper in the library).  So an abstract base class might be a good 
idea, with subclasses implementing the actual construction and some of 
the basic methods.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org