Re: [xml] problem with gzip decoding in nanohttp

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

----- 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 Veillard      | Red Hat
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]