[Twisted-Python] HTTP versions

[Andrew Dalke]

Itamar:
> I don't really care about this, working with real life code is more
> important. But if you send me a patch I'll accept it.

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.

What about something like

class Version:
   def __init__(self, s, v):
     self.s = s  # a string, as in "HTTP/1.1"
     self.v = v  # a 2-ple, as in (1, 1)
   def __cmp__(self, other):
     if isinstance(other, Version):
       return cmp(self.v, other.v)
     if isinstance(other, basestring):  # or as appropriate for Python 
2.1
       # generate a deprecation warning here
       return cmp(self.s, other)
     return cmp(self.v, other)
   def __rcmp__(self, other):
     return -cmp(self, other)
   def __getitem__(self, i):
     return self.v[i]

which would be an interim solution that would pass the
existing regression tests and provide a transition to a 2-ple
based version.


>> I noticed that the headers parsing assumes unique names, with
>>
>>          self.requests[-1].received_headers[header] = data
>
> This is indeed a problem. I had a patch that solved it, but had to back
> it out. Sooner or later it will be reintroduced.

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

> Twisted depends on 2.2. If you want code to be added to Twisted, it'll
> have to require 2.2 only. We also ned backwards compatability with
> existing code. Most of the problems you mentioned can be solved with
> only a little work using the existing codebase.
>
> Probably what you should do is write a series of patches and send them
> to me. They'll have to be backwards compatible, have tests and work on
> 2.2 in order to be accepted.

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!)

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

"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?

I can make the existing regressions all pass, but a review of the
regressions show that it doesn't test everything that could be tested,
so I need to either ask questions first (as I'm doing) or be extreme
about it and say that if it passes the tests then it must be fine ;)

					Andrew
					dalke at dalkescientific.com