Re: [xml] problem with gzip decoding in nanohttp

["Liron" <magilam netvision net il>]

Hi Daniel,

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/