Does it make a difference with "AcceptFilter http none" configured? It shouldn't, but since we are in the x-files...
On Thu, Oct 22, 2015 at 4:52 PM, Andy Wang <aw...@ptc.com> wrote: > So this is the problematic request: > 000002D0 6e 74 2d 54 79 70 65 3a 09 74 65 78 74 2f 70 6c nt-Type: .text/pl > 000002E0 61 69 6e 0d 0a 0d 0a 0a ain..... > > This is a "regular" request using HttpPRequester extension or just using > ncat or curl: > 000002D0 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c nt-Type: text/pl > 000002E0 61 69 6e 0d 0a 0d 0a ain.... > > Ignore the 0x09 and 0x20 difference. I had him fix that already and it > didn't make a difference. > > I recreate the exact same request as the problematic request by adding a > 0x0a to the end of it but it doesn't recreate the problem. > > Andy > > On 10/22/2015 08:59 AM, William A Rowe Jr wrote: >> >> On Thu, Oct 22, 2015 at 8:42 AM, Andy Wang <aw...@ptc.com >> <mailto: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. >> >
