Suggestion: "Completing" HTTP support in Python.

Robb Shecter shecter at darmstadt.gmd.de
Fri Jun 16 09:13:34 EDT 2000


(I'm cc'ing you because I'm posting to the other thread where the
conversation has been...)

>I wrote:
>> Wishful example #1
>> --------------
>> h = HTTP('my.host.name', '/loginscript', 8080)
>> h.add_parameter('username', 'Robb')
>> (code, msg, headers) = h.post()
>>
>> Wishful example #2
>> --------------
>> h = HTTP('my.host.name', 8080)
>> h.add_header('X-local-hack', 'true')
>> (code, msg, headers) = h.get()

You wrote:
>Surely this level is higher than HTTP.

I disagree.  I think that an HTTP request can be seen as a black box
with these "knobs", or inputs:

Destination URL (host, port, path)
A set of parameters
A set of headers
A method (GET, POST ... I'm not interested in the others)

...and then, this black box should have a big "send" button on it,
which results in the usual python 3-tuple popping out.  All of these
items are specified in the RFC.

>The way in which forms are posted...

I wasn't thinking about forms at all.  Maybe everyone else here is,
and that's fine.  I've built an XML/HTTP middleware system that uses
POST's with parameters for requesting remote procedure calls.
Something like XML-RPC, but more intelligent. :)

>If you are looking for a more high level approach then why not try
>something like this:
>http://cobweb.quantisci.co.uk/pub/english.cgi/d8014813/cl_forms.py

Hmm... maybe I could hack that up and use some parts of it, but it
looks very HTML form-specific.

>I for one, would be interested in this kind of functionality for the
>library - my own attitude has been to simply "knock one up" as and
when
>I've needed it.

Exactly - I'd guess that everybody's been (re-)doing that kind of
work.  When I have something to show, I'll post it...

- Robb




More information about the Python-list mailing list