aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/exttst
diff options
context:
space:
mode:
authorShawn O. Pearce <spearce@spearce.org>2011-02-15 14:09:42 -0800
committerShawn O. Pearce <spearce@spearce.org>2011-02-15 16:32:51 -0800
commit18e822a7fefb35e4a68ca4b337541c0a1a222a43 (patch)
tree2a3367ce07ae4de47c0290e0c078ab45eeb6d53e /org.eclipse.jgit.test/exttst
parentf194eeb71fdeddbaf0458bf421cdae50f1e93809 (diff)
downloadjgit-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