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:

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.