Petr, > "I'm afraid is is not so simple:"
I'm pretty sure it is--for that question, as asked. Read the original poster's question again, and see if you don't agree. It really does seem to ask the very basics of the "handshaking" that goes on for requesting compressed resources: the caller indicates a willingness and capacity to deal with certain compression schemes in the resource request; the server indicates whether it is capable, ready, AND whether it actually DID serve the resource back in which of any of the encodings the caller said it could take. > "it does not mean that you could rely ..." Heh... Kinda like with all the RFCs, and all implementations... BUT, in the overwhelming majority of cases, that's a pretty good indicator. > "The key question is, what kind of data it is and who serves those data for you... " Yup. I have met strangely configured servers too, returning CSV files/resources identified as appl/XLS, and EVEN executables listed as plain text... But identifying the TRUE format of a resource is a different issue; would have been asked differently; and c/w/ould be a lot (!) harder to answer, and to code. <G> > IMHO a *reliable* way to detect gziped content is > - to check identification and CRC of content whether > it follows RFC 1952 > - to try to decompress the content I agree, but as a first (2nd & 3rd) implementation I'd just try to decompress (which will fail on bad input), and then ONLY if more performance was needed (seems unlikely), I'd go to a header and trailer check, as in RFC 1952 (which would partially duplicate what the decompression routines are doing). BUT there would be quite a few other very short and quick validity and sanity checks that could be performed (only on those headers and trailers) much faster than the CRC scan and computation of the entire payload. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public
