On Thu, Oct 22, 2015 at 8:42 AM, Andy Wang <aw...@ptc.com> wrote: > > On 10/21/2015 10:01 AM, Andy Wang wrote: > > I will do that today. >>> >>> And thank you to Rudiger and yourself, and everyone else on the thread >>> for all the help. >>> >>> I missed the trailing 0x0a in the different wireshark captures. I was >>> trusting wireshark's http dissection rather than looking at the raw hex >>> data and it didn't show the trailing \n. >>> >>> I gotta go back to the basics and lean less on wireshark's >>> "intelligence" :) >>> >> >> Oh, and the plugin developer actually identified where the \n was coming >> from and has resolved it on the client end. >> >> I do have one question. Any idea why this only occurs on Windows servers? >> > > Tested with the patch and looks good. > I tried to recreate it using ncat and sending an extra \n but I'm not > having luck. I see the extra byte on my pcap. Still curious what other > conditions create this but oh well, at this point it's in my > rear-view-mirror. > > Thanks again for all the help and the solution. > Andy >
I can't help but wonder if the '\n' is consistent but a '\r' is injected on Windows... are you sure the variance was strictly a '\n'? Generally an httpd module emits exactly what it means, whether it is a unix '\n' line ending, or an http '\r\n' sequence as defined by spec. But with generated content, you are more likely to see variances based on whatever API generated the content, and lots of code will generate \n on unix vs. the \r\n sequence on Windows - httpd didn't influence that.
