On 6/11/07, Dan Christian <dchristian@google.com> wrote:
> I've got 2 major operational problems with serf at the moment (this is after
> Jason fixing several issues. Thanks!). Neither is technically a serf
> issue, but they none the less make serf un-usable.
>
> serf over SSL trips a core dump due to a double free bug in
> libcrypto-0.9.8/libssl-0.9.8. neon hits this as well, but serf hits it much
> more often. I can't get through any of my big test cases without a fault.
Huh. If you can provide some information about this, I'll see what we
can do - but if Neon hits it too, then it's likely an OpenSSL bug...
=(
> serf doesn't play well with some http-1.1 implementations (specifically
> code.google.com). neon does fine here. It raises the issue of how many bad
> http-1.1 implementations there are and how to validate serf to be "good
> enough" to be the default.
Well, to be quite emphatic: Google does *not* support HTTP/1.1 - it is
a quite blatant RFC violation on Google's part. While I was at
Google, Greg and I talked at length about whether we should work
around it in serf - and we came to the opinion that it is reasonable
for serf to expect RFC-compliant server implementations. Everyone
else is going to be using Apache or IIS or Squid which doesn't have
this particular brain damage with respect to the RFC - and,
realistically, almost everyone will be using Apache 2.x. So, I don't
support crippling serf just to support non-compliant HTTP/1.1 server
implementations - even if it is Google. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 11 20:44:02 2007