Re: [xml] problem with gzip decoding in nanohttp

["Liron" <magilam netvision net il>]

Hi Daniel,

(I should really control my email client better and send those messages 
directly to the group...sorry... again)

You're absolutely right about the "don't fix it if it ain't broken" approach
but after reviewing the code I think that it's badly broken and I'll
explain:
It's true that those functions do different things but the common thing for
all of them is reading from a socket. As I explained, the bug I found will
occur in every function that reads content (as opposed to headers) from the
socket and not using "inflate" when the content is gzip encoded. The only
function that decompresses the content is xmlNanoHTTPRead BUT it's not the
only function that delivers content.
xmlNanoHTTPFetch is a function that opens a URL and saves the content to
file, if you're telling me that this file should contain encoded data in
case that gzip is used then we don't have a problem (I think it's wrong but
if it's by design...). But if you do expect the output file to contain html
for example then it won't work.

Like I said, I didn't review the code enough to make the changes (or get
permission to do so yet ;)) but it looks like xmlNanoHTTPRecv and ONLY
xmlNanoHTTPRecv should be changed to support the decompression since every
function that reads from the socket calls it (but not every function that
calls it decompresses the content)

If you want to test it, simple use xmlNanoHTTPFetch on any site that
supports gzip and see what I mean.

Another issue I wanted to ask you about is the content-length when the
content is compressed. If content-length header exists it'll return the
length of the compressed data so I applied a new function that simply
returns whether the content is gziped or not. This is good for applications
that depends on the content-length header for buffer allocations so they
should be aware if this field contains the right number or not (Just a
helper function).

I hope I made myself clear here, please let me know what you think
Liron

----- Original Message ----- 
From: "Daniel Veillard" <veillard redhat com>
To: "Liron" <magilam netvision net il>
Cc: <xml gnome org>
Sent: Thursday, January 26, 2006 6:09 PM
Subject: Re: [xml] problem with gzip decoding in nanohttp

>  I still don't understand your problem w.r.t. the code.
> All those function do different things as their doc explains, some read
> at the low level, some are line read public API, some are block read API
> and the last one read and save to a file. The functions are different
> because they implement different interface, to me that's fine, they
> are actually layered.
>  So explain the bug(s), explain why you think there is duplication,
> I can't see anything obvious even in the light of your last message.
> And if it's only 'cleanup' sometimes the 'don't fix it if it ain't
> broken' approach to maintainance is just fine, but I'm listening.
>
> Daniel
>
> --
> Daniel Veillard      | Red Hat http://redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/