Specifically, the upstream server is quoting the boundary string, and then followin git up with ", application/plain". Which I'm guessing is not valid according to the RFC, but I'm not well versed in it.
golions-
It would help if you could run "bzr pull -Dhttp" and attach that log. As it will write out more details about the specific HTTP requests being made.
I think this is actually different from the original bug. Namely the original bug is that we trigger some proxies to fail to return anything, while your problem is that the boundary string is not being parsed correctly.
Something isn't right about the boundary line.
Specifically, the upstream server is quoting the boundary string, and then followin git up with ", application/plain". Which I'm guessing is not valid according to the RFC, but I'm not well versed in it.
golions-
It would help if you could run "bzr pull -Dhttp" and attach that log. As it will write out more details about the specific HTTP requests being made.
I think this is actually different from the original bug. Namely the original bug is that we trigger some proxies to fail to return anything, while your problem is that the boundary string is not being parsed correctly.
My guess is that Savannah is returning:
Boundary: "b)LkBW? GfofYxLSueNd1" , application/plain
Rather than
Boundary: "b)LkB..."
Content-type: application/plain
We probably could work around this in bzr, but it seems more like something that Savannah is doing wrong.