Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.
Spent a few days battling an error on an HTTP Send Port. We've been having messages suspend when posting data to Siebel. The funny part is that the messages got accross ok. We were only getting the error on the ACK from the send port. The error message on the suspended message was:
The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
We brough this up to the Siebel guys but they were a little slow moving on the informatio that they were sending us bad responses. After a few days I got nervous that the problem may have not been on their end. So I dragged out NetMon. And here's what I saw:
Frame: + Ethernet: Etype = Internet IP (IPv4)+ Ipv4: Next Protocol = TCP, Packet ID = 50895, Total IP Length = 467+ Tcp: Flags=...PA..., SrcPort=HTTP(80), DstPort=1427, Len=427, Seq=2928398986 - 2928399413, Ack=4246831364, Win=64240 (scale factor not found)- Http: Response, HTTP/1.1, Status Code = 204 - Response: ProtocolVersion: HTTP/1.1 StatusCode: 204, No content Reason: No Content Date: Thu, 15 May 2008 20:28:51 GMT Server: Microsoft-IIS/6.0 XPoweredBy: ASP.NET process instance id: 1-1DEHL5 user-agent: Microsoft (R) BizTalk (R) Server 2006 3.0.1.0 datahandlingsubsystem: HRFQADProductInbound transporttype: HTTP expect: 100-continue object id: 1-Z02HX connection: Keep-Alive cache-control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Host: mlbsbltst1vm HeaderEnd: CRLF
So I dragged out RFC 2616 to go over what the HTTP Header should look like. I found that the header field name should be a token and that the definition of a token is:
token = 1*<any CHAR except CTLs or separators>separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
So, in the aforementioned header the following fields are of interest:
process instance id: 1-1DEHL5 object id: 1-Z02HX
They are bad. BizTalk is right. Working on the Siebel guys to take out these custom header fileds (or make them compliant at the least).
The problem troubleshooting something like this is that BizTalk chokes on the message in the pipeline and it doesn't get captured anywhere. I had to reproduce it in an environment where I could use NetMon to grab the actual data from the wire.
Remember Me
