[Twisted-Python] HTTP versions

[Itamar Shtull-Trauring]

On Sun, 1 Jun 2003 17:54:45 -0600
Andrew Dalke <dalke at dalkescientific.com> wrote:

> I can send a patch, but I don't know the dependencies of clients
> on having a version string over a 2-ple, which is what I would
> prefer.

All backwards compatability has to be in the Request class interfaces -
whatever stuff a end user might be using.

> What about using just rfc822.Message?  That's in Python 2.2.

Not good enough - MIME stuff should be stored on disk if its large (i.e.
file uploads). I did it using cgi.FieldStorage, and it was backwards
compatible too, but it broke twisted.web.distrib, which *sucked* :(
distrib needs to be fixed so it gets a stream, and then we can mess with
Request as much as we want.

> I used the wrong term.  I said "replacement" when I should have
> said "in addition to".  That is, code which would eventually become
> the standard code for Twisted once it requires 2.3 (after all, 2.3
> isn't out yet!)

I'd have to see the code before deciding.

> My major complaint, by the way, is not that there are small problems
> with the code.  It's that Twisted duplicates functionality from
> standard Python, when the Python code is just as usable for that
> situation and has fewer problems.  And going the other way, the Python
> 2.3 implementation
> doesn't have the "\r\n" workaround Twisted has for handling IE
> problems. If those could be combined, then there are more people
> supporting the same
> codebase, so hopefully fewer bugs, and easier to share experience 
> between
> the two.

A lot of this is for historical reasons - Twisted only depending on
1.5.2, and then 2.1. 2.2 support is really new.

> A downside is the dependency on Python releases to fix patches, but
> any bugs at this point will be distributed at the patch level, and
> there's always the possibility of just including the patched code
> with Twisted until the next Python update.

Because we can release Twisted so much faster, we usually prefer to just
patch Twisted.

> "Backwards compatible" is somewhat of an issue.  I don't know which
> methods are published and which are unpublished.  Is it expected that
> people will (or do) derive from twisted.protocols.http.HTTPChannel ?
> If so, then can I change the behaviour or simply eliminate the
> headerReceived method?  (I would rather accumulate all headers then
> parse them into a Message in one go.)  What about the other methods?

Request methods and attributes that users are likely to use is what
counts.

-- 
Itamar Shtull-Trauring    http://itamarst.org/
http://www.zoteca.com -- Python & Twisted consulting