Mercurial > pidgin
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 |
---|