Cannot fetch from remote about squot HOT 6 CLOSED

The feedback button does use an own WebClient instance, does it? Then I cannot explain the ConnectionClosed there. The tests do sometimes fail in the CI builds with similar errors about stream codes. The server sends progress and pack data interleaved in several "streams" which are identified by a number at the start of each packet of git's own protocol that is used for the HTTP body. The errors either mean that additional stream IDs have been introduced, or that sometimes parsing of the git protocol errs, for whatever reason. I guess the latter is the more likely answer... The tests usually succeed on the second try. Does the problem persist in your case?

from squot.

Maybe this helps you making sense out of this: the corresponding stream contains the following:

 'Counting objects: 12347, done.
002a�, done.
Compressing objects:   0% (1/352)   
004f�Compressing objects:   1% (4/352)   
Compressing objects:   2% (8/352)   
002b�Compressing objects:   3% (11/'

I'm guessing that's where the 32 is from? "11/32"?

from squot.

The feedback button does use an own WebClient instance, does it? Then I cannot explain the ConnectionClosed there.

No, it just uses WebClient>>htmlSubmit:fields:method:. Maybe @krono has an educated guess?

from squot.

not off hand. let's look tomorrow

from squot.

 'Counting objects: 12347, done.
002a�, done.
Compressing objects:   0% (1/352)   
004f�Compressing objects:   1% (4/352)   
Compressing objects:   2% (8/352)   
002b�Compressing objects:   3% (11/'

I'm guessing that's where the 32 is from? "11/32"?

No, the 32 would be the decimal value of a byte following the four-byte hexadecimal length indication of a pkt-line. 32 is a space in ASCII, so the GitProtocolReader read four bytes in front of a space as a length indication for some reason.

Is the above string the content that has already been read or is it the content of what was not read yet? Or is it a buffer and I cannot tell where the position is?

Anyway, there is something fishy here:

002a�, done.
Compressing objects:   0% (1/352)   

This is 50 bytes long (with LF newlines), but 2a (42) is indicated as the length. Reading only 42 bytes, the pkt-line would stop after (1/, then 352) would be read as the length of the next line (since ) is not a hexadecimal digit, this should produce an error, but Integer class>>readFrom:base: just ignores it). The following byte is indeed a space.

Questions remaining: Is my analysis correct, who sent that bogus pkt-line and why?

from squot.

Solved by updating to the latest version of WebClient.

from squot.