Daniel Stenberg wrote:
>
> On Thu, 10 May 2001, Cris Bailiff wrote:
>
> > This is likely to be a problem in other headers as well - white space is
> > allowed anywhere within the headers, and is all equivalent. I haven't
> > examined all the others, but I suspect ranges and 'Transfer-Encoding' may
> > also be trouble.
>
> Indeed, this problem exists on serveral places in Tranfer() (lib/transfer.c).
>
> A good solution is probably to split up the comparisons from checking
> strnequal(headerline, "header: content", length) as one string into a check
> that splits the header and the content and checks them separately, like:
> compareheader(headerline, "header", "content").

Yes, this seems like a good solution.

I might suggest a flag which can switch compareheader to 'strnindex'
instead of 'strncmp' , because a number of headers can be multivalued,
and you might need to search for a token. My immediate example is
'Transfer-Encoding' --- 'chunked' is one option, but there are also
'gzip' (not that I've seen it used in practice), 'ident' and random
others. They can be used (theoretically) in combination. At the moment
gzip is usually signalled on the actual content (with Content-Encoding)
rather than the hop-by-hop Transfer-Encoding, but even there, you can
have 'gzip' or 'x-gzip', so when libcurl supports compression, you'll
need to check for both.

> However, curl has had this "flaw" since the beginning and it was only found
> yesterday. It proves how minor this problem actually is...

I noticed it in the code, and figured I'd wait for the problem to bite
before worrying too much, but I notice that header variations were
already noted/fixed with Sun Java Web server etc. I guess when my
toaster has a buggy web server in it, I won't be able to pop the toast
with curl - back to good old SNMP...

Cris
Received on 2001-05-11