I just ran into an issue where juce_getInternetFileContentLength returns an incorrect (too short) length , which causes that URL::readEntireTextStream to return a truncated content. The issue happens on Leopard, not on Snow Leopard. Forcing juce_getInternetFileContentLength to always return -1 fixes the issue. I’m not using the very latest git head, but my juce sources are not too old (1 month ago) and I don’t think anything relevant has changed since then. Looking at the raw http headers received with wireshark, it looks like I’m receiving gzipped content, and the content length reported is the length of the gzipped data, while the length that juce expects is the length of the ungzipped data .
Weird - I just had exactly the same report from someone else today, though the code’s been working the same way for years!
It’s a tricky one since it’s the webserver that’s returning the bogus length, and I can’t really think of a better fix than setting the length to -1. That’s a pity though, because it means you can’t easily work out your download progress…
And a thought: I’d imagine that exactly the same thing will happen on win32 and linux, as they all just grab the length from the headers that the server returns. Very annoying…
Hi jpo,
Try downloading the file using web browser. Check if you can see correct progress for download and also if it shows the file size. If it doesn’t show the correct values, it means that the server is not sending correct information.
No I checked, the server is reporting the correct answer (it reports the length of the data that will be downloaded, not its length after decompression). It is macos that has changed its behaviour, in leopard “contentLength = [response expectedContentLength];” reported the “Content-Length” header, which is used by JUCE assuming this is the length of the gunziped data and causes truncation, while in Snow Leopard, it seems to ignore the “Content-Length” returned by the server and just returns -1.
This one just bit me as well. Same scenario as the others reported. Broken in 10.5, working in 10.6. I’m not using the absolute latest tip, but fairly recent. Also, I’ve noticed that it does work in 10.5 when the server response is rather short (e.g. less than 100 bytes).
Uhm I’m working on it, and I think this is a problem of MacOS X 10.5 implementation, thus the patch should apply only to Mac code that gets compiled with 10.5 support. This restricts the “ugliness” of the patch.
In addition, why not storing the “-1” length only during the actual retrieval of the data from the network? Once all the data has been received, I think its correct length is known and can be stored in the contentLength member of JuceURLConnection, what do you think about it?
I’ve just checked in some code where I’ve refactored the streaming stuff so that it doesn’t rely on the stream length when reading into a memory block. This won’t fix the fact that the length is reported wrongly, but it should fix the problems that you’re seeing when you call things like readEntireTextStream()…
