Peeker is zero-length after parsing a file #25
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The nuget client (which I am programming a server for) is sending a request which looks like this:
And is causing an Error::Eof.
Updated, see below
After debugging with gdb it seems that
peekeris a zero-length slice after parsing the file. I have no idea, how that might happen.Returning early correctly parses the upload, as expected:
Thanks for the report and the debugging.
I've tried to create a test case that replicates your data so I can consistently reproduce the incorrect behaviour. It currently has a wrong (made-up) content length, but it is nonetheless useful because it is currently reporting "The request body ended prior to reaching the expected terminating boundary," so I do believe we have a test case that shows the failure.
It's on the nuget_test branch.
Now, onwards towards solving this...
I can provide you with a complete request dump, if that helps. I just shortened it for the report. Also that request does get send as a PUT (different to your test case, which is POST), although that probably does not make any difference for parsing.
Yes, please supply the full request. I suspect that the Content-Length header does not match the body content length exactly, perhaps due to character encoding surprises.
... or the final boundary is not preceded by a CRLF.
I've verified that boundaries starting with lots of hyphens is not an issue.
The nuget client is very picky about the Servers it accepts and requires a chain of requests to succeed, before it will finally send the failing request. Iron does not give me the Raw Request, so I can only give you the complete Raw Body and all Headers in human-readable format, without writing a new server with another framework. I hope that is sufficient.
The Request logged (including Headers):
The Body (Raw File https://www.dropbox.com/s/yq9tb5kipjfvvqv/tmp?dl=0 ):
It should be a CRLF after the file end for various reasons:
The raw file has the following bytes preceding the final boundary: 0D 00 00 00 00 0A
The four NUL bytes separating the CR from the LF make it an invalid CRLF.
stream_until_token reads right up to the end, fails to find the token, and returns Ok(n) (the comments above the function say it returns Ok(n) even if the token was not found). Then it goes back to ParsingHeaders, but the buffer is now empty.
I hope I did not dump it wrong, as this seems really weird and I am not sure, why the client should do this. I will try to verify that the actual request is this messed up
I am suspecting, that the actual line ending might be an LF instead of a CRLF and the CR is actually still part of the binary file.
Okay so the actual code in the nuget client, that constructs the request is the following:
https://github.com/NuGet/NuGet2/blob/2.11/src/Core/Http/MultipartWebRequest.cs
As one can see in line 17 and 74 the "\r\n" is hardcoded (which means it's not unix, that is inserting just an "\n") and correctly added to the request. I also verified that in my Mono Runtime the byte representation of \r\n is actually 0x0D0A.
But even wireshark is showing the "0D 00 00 00 00 0A", so I am very confused how that happens.
Thanks anyway.
Quick note, if anybody encounters this: The 0D is actually not part of the CRLF (tested with other files), so its probably still a unix issue.