From: SourceForge.net <no...@so...> - 2009-04-19 16:27:13
|
Bugs item #2715421, was opened at 2009-03-26 20:59 Message generated for change (Settings changed) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2715421&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 29. http Package Group: obsolete: 8.5.6 >Status: Closed >Resolution: Fixed Priority: 8 Private: No Submitted By: Alexander James Pasadyn (ajpasadyn) Assigned to: Pat Thoyts (patthoyts) Summary: POST appending a newline character Initial Comment: It appears that when sending a POST, a newline character is being appended to the end of the data. The body is then one byte longer than the content-length in the header, I have a web server that's complaining about it. It appears that commenting out the offending puts statement works for us, but since it looks like that was deliberately done maybe there is something else out there that expects it? ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2009-04-19 17:27 Message: this has missed 8.5.7 but I will apply this fix to 8.5-branch and HEAD. I've got tests added for the HEAD branch to check for excess bytes being POSTed now. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-03-27 17:09 Message: So let's remove that line. It violates the RFC by lying on the Content-Length by one for no reason. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2009-03-27 16:36 Message: The history for the http1.1 changes is in tclvfs/http as that is where this was done. Jeff ported most of it over in one lump into the core at some point however it looks to me like this particular change was merged into the tclvfs version from the core version by Jeff. I never made any attempt to provide chunked support for POST however - afaik we only support chunked for reading. I think it more likely to be something to force successful upload of files to some server or something similar. In the absence of sensible comments and/or tests it should conform to the rfc. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-03-27 07:34 Message: Oh I see, it might be the remnant of an attempt to support Chunked transfer upstream, the empty line being the current chunk's trailer (in the POST body). However, it seems that currently this support is only for downstream. Moreover, RFC2616 says that chunk headres and trailers are all based on CRLFs, not LFs, while at this spot we are in [-translation binary]. So it would be an invalid trailer anyway. Pat, any other consideration before removing that line ? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2009-03-27 00:18 Message: You are correct that the [puts $sock ""] (line 886 of 8.5-head and 905 of 8.6-head) went in at that point. It was part of a larger chunked encoding handling patch. I cannot justify clearly why it was added from review. I am deferring to Pat to comment on whether this last newline was in any way correct for chunked transfers (something he's done more with), or simply an errant bit of code in the larger patch. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-03-26 23:58 Message: Jeff, this 'puts $sock ""' line was added by you on line 885 of version 1.66. It is part of a big set of changes, but locally it stands rather alone (apart from var renaming). The commit log doesn't mention it. What was the intention ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2715421&group_id=10894 |