I realize that I'm the one driving this issue, so this might
sound selfish, but I do think that this "rare" situation
warrants a change in the code.

I've written some perl-based link validators, and run them
against databases of thousands of URLs. Server behavior that
you might consider highly unusual pops up a lot more than you
might think (example: there are a _lot_ of servers that will
return a 500 or even a 404 on a HEAD request, but a GET for
the same document will return 200!).

When using a tool as a link validator (something which curl
is quite good at), you have to have complete trust in your
tool. The point remains that the coders of the major browsers
wrote them to send the request as a single "chunk". This means
that when server-side hardware and software developers test their
products, they'll test against similar clients. Right or wrong,
that's the reality that is the Internet today. A lot of protocol
implementations that get it 99.5% right.

Upon my cursory examination of the code, I don't think that a
complete rewrite is necessary to implement this fix. If you
change lines 316-512 of http.c to simply assemble a buffer with
the HTTP request and then use a single sendf, I would think that
would suffice.

I'd be happy to help out with that. (It's been some time since
I've done any heavy C coding, though. I'd hate to introduce a
memory leak or a buffer overrun.)

Jason Priebe
WRAL OnLine
http://www.wral-tv.com/

> -----Original Message-----
> From: Troy Engel [mailto:tengel_at_sonic.net]
> Sent: Monday, September 25, 2000 11:04 a.m.
> To: curl_at_contactor.se
> Subject: Re: hanging URL
>
>
> Daniel Stenberg wrote:
> >
> > Then again, the browsers seem to send a one-shot request
> which makes them
> > survive this "terror". Curl is made very much with the
> intention of emulating
> > a browser. Shouldn't curl then emulate the browsers to this
> extent as well?
> > ...
> > I'll have to think about this a bit further. If anyone has
> any additional
> > views on this, or plain suggestions, feel free to post them!
>
> Well, from here I don't see this issue popping up a lot on the list,
> which leads me to believe it's a very rare situation. Is it worth the
> effort of a complete redesign (which works everywhere else) to
> accomodate one server?
>
> From the user's point of view, sure! They're not doing the work, and
> they want the server to work. :-) Under normal
> circumstances, wouldn't
> we contact the server operator to figure out why *their* end
> is broken?
>
> Just my $0.02, US.
> -te
>
> --
> Troy Engel :: KeyID DF3D5207
> Perl is just another tool in the Unix toolbox. Perl does one thing,
> and it does it well: it gets out of your face. - Larry Wall
>
Received on 2000-09-26