comparison pixmaps/gaim.ico @ 9240:f1d87ab17e41

[gaim-migrate @ 10039] wing writes: While working on patch 967849, found that there are a few problems with current Content-Length handling: 1. parse_content_len uses a single sscanf on data. However, data (the response headers) would begin with the http status, not the Content-Length 2. data is not nul-terminated, but sscanf assumes a nul-terminated string. This could (though very unlikely) be unpredictable if input is malformed. 3. if gaim_url_fetch succeeds in extracting the Content-Length from the response headers, it will silently discard all the data after they have been read, because it does not keep track of whether the specified number of bytes has been read (The "else" case that corresponds to this situation is an empty block.) The attached patch corrects the above problems, though the patch is still technically not correct, since Content-Length theoretically should be matched case-insensitively. He then revised the patch and wrote: More problems, unrelated to content-length handling, have been discovered: 1. Gaim's http/1.1 support is broken; http/1.1 clients are _required_ to be able to decode the "chunked" transfer encoding, but gaim cannot do it. Since the difference between gaim's http 1.0 and 1.1 support is only to send the Host header, which is not forbidden in http 1.0, I have changed gaim's http 1.0 behaviour to also send the Host header. This is required for Yahoo Japan "avatar" support. (The server requires a Host header but sends the image in the chunked encoding, which gaim cannot decode.) 2. User-Agent should not be quoted committer: Tailor Script <tailor@pidgin.im>
author Tim Ringenbach <marv@pidgin.im>
date Wed, 09 Jun 2004 01:24:47 +0000
parents 42f9ebe32de4
children
comparison
equal deleted inserted replaced
9239:3434d420fe69 9240:f1d87ab17e41