diff options
author | Shawn O. Pearce <spearce@spearce.org> | 2011-02-15 14:09:42 -0800 |
---|---|---|
committer | Shawn O. Pearce <spearce@spearce.org> | 2011-02-15 16:32:51 -0800 |
commit | 18e822a7fefb35e4a68ca4b337541c0a1a222a43 (patch) | |
tree | 2a3367ce07ae4de47c0290e0c078ab45eeb6d53e /org.eclipse.jgit.test/exttst | |
parent | f194eeb71fdeddbaf0458bf421cdae50f1e93809 (diff) | |
download | jgit-18e822a7fefb35e4a68ca4b337541c0a1a222a43.tar.gz jgit-18e822a7fefb35e4a68ca4b337541c0a1a222a43.zip |
smart-http: Fix recognition of gzip encoding
Some clients coming through proxies may advertise a different
Accept-Encoding, for example "Accept-Encoding: gzip(proxy)".
Matching by substring causes us to identify this as a false positive;
that the client understands gzip encoding and will inflate the
response before reading it.
In this particular case however it doesn't. Its the reverse proxy
server in front of JGit letting us know the proxy<->JGit link can
be gzip compressed, while the client<->proxy part of the link is not:
client <-- no gzip --> proxy <-- gzip --> JGit
Use a more standard method of parsing by splitting the value into
tokens, and only using gzip if one of the tokens is exactly the
string "gzip". Add a unit test to make sure this isn't broken in
the future.
Change-Id: I30cda8a6d11ad235b56457adf54a2d27095d964e
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Diffstat (limited to 'org.eclipse.jgit.test/exttst')
0 files changed, 0 insertions, 0 deletions