Fix that exceptions in ReceivePack cause Invalid Channel 101 exceptions
When during a PushOperation the server hits an exception different from
UnpackException the JGit server behaved wrong. That kind of exceptions
are handled so late that the connection is already released and the
information whether to talk sideband to the client is lost. In detail:
ReceivePack.receive() will call release() and that will reset the
capabilities. But later on the stack in ReceivePackServlet.doPost() it
is tried to send a response to client now with reset capabilities (no
sideband!).
Change-Id: I0a609acc6152ab43b47a93d712deb65bb1105f75
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Provide more details in exceptions thrown when packfile is invalid
Mention packfile path in exceptions thrown when we detect that a
packfile is invalid and make excplicit that corrupt packs are removed
from the pack list.
Change-Id: I454ada5f8e69307d3f34d1c1b8f3cb87607ddf35
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Revert "Extract path info from requests without decoding"
This reverts commit 19f869996f.
Leaving path info encoded confuses applications like Gitiles.
Trying to fix this inside of JGit was maybe the wrong solution.
Change-Id: I8df9ab6233ff513e427701c8a1a66022c19784eb
Fix LocalDiskRepositoryTestCase to create correct type of repos
In one place LocalDiskRepositoryTestCase was ignoring the specification
whether to create a bare or non-bare repository. Fix this and fix also
one test which fails now because bare repos don't write reflogs by
default.
Change-Id: I4bcf8cf97c5b46e2f3919809eaa121a8d0e47010
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Gitiles malfunctions in conjunction with jgit and guice
because of a recent Guice bug fix. Work around the problem
by parsing the URI directly, bypassing the unescaping
performed by the getPathInfo method.
This rest of this message is copied from
https://gerrit-review.googlesource.com/#/c/60820/ :
The fix for Guice issue #745[1] causes getPathInfo() within the
GuiceFilter to return decoded values, eliminating the difference
between "foo/bar" and "foo%2Fbar". This is in spec with the servlet
standard, whose javadoc for getPathInfo[2] states that the return
value be "decoded by the web container".
Work around this by extracting the path part directly from the request
URI, which is unmodified by the container. This is copying the Guice
behavior prior to the bugfix.
[1] https://github.com/google/guice/issues/745
[2] http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getPathInfo()
Change-Id: I7fdb291bda377dab6160599ee537962d5f60f1e8
Signed-off-by: David Pletcher <dpletcher@google.com>
Matthias Sohn
Christian Halstrick
Shawn Pearce
David Pletcher