[xml] Why the strncasecmp() avoidance?

Date view Thread view Subject view Author view

From: Wayne Davison (wayned@blorf.net)
Date: Thu Sep 21 2000 - 18:02:48 EDT


This is along the same line as the recent comment about xmlHasProp() being
case-sensitive. For some time now I've noticed that the HTML/HTTP-parsing
code often only allows certain configurations of upper/lower-case in
various tags and headers. For instance, the nano-HTTP code does not match
the "Content-type:" header that comes back from Netscape-Enterprise/3.6
SP2 because it only allows 2 variations to match ("Content-Type:" and
"content-type:", not counting the ones without the dash in the middle).
Something similar happens in all the tag-matching code (such as only
looking for "HTTP-EQUIV", "Http-Equiv", and "http-equiv" on META tags).

Thus my question is, why doesn't the code use strncasecmp() for this kind
of thing? I know that older machines may not have an implementation of
this routine, and that it may not handle non-ASCII charsets, but these are
soluble problems (i.e. I have an implementation of strncasecmp() that can
be included in libxml, and we only need to use it to compare ASCII strings).

So, shall I jump in and change a bunch of code to use strncasecmp()? Or
shall I hard-wire the code to use an internal xmlStrncasecmp() routine in
all instances? (Which would alleviate concerns about some versions of
strncasecmp() out there not working properly.) Or is there some other
solution to this problem?

In the meantime, the appended patch makes the nano-HTTP parser understand
the Content-type header.

..wayne..


----
Message from the list xml@rpmfind.net
Archived at : http://xmlsoft.org/messages/
to unsubscribe: echo "unsubscribe xml" | mail  majordomo@rpmfind.net


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Sep 21 2000 - 18:43:14 EDT