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.