Share via

Replication: Header information is either corrupted or missing

  • Article

I have seen this issue many times and decided to share my experience and how this issue may be resolved:

Problem:

I have installed a SQL Server 2005 and IIS on the same machine and all is working fine via HTTP. SQL Server Mobile connects, the subscription is created, and a complete synchronization is executed. However I would like the mobile device to be able to connect to the site when I’m not in the office, so the web site is web published (in this case ISA). When I try to synchronize I get the following error:

Header information is either corrupted or missing

Hresult -2147012746 Integer

NativeError 28035 Integer

Analysis:

SQL Merge Replication/ RDA may break if the HTTP response is changed to a different format where there is no Content-Length header. This can happen for a number of reasons and in ISA the most common reason for this is because Link Translation is being applied to the web publishing rule. Link Translation in ISA is used to ensure that internal URLs, names and references are correctly translated, so that an external clients do not try to connect to an Internal URL. For this to work ISA must scan anything from the headers of the request/response to the body to replace these strings.

As a request/response can be quite large it’s important that ISA handles this in the most scalable way and doesn’t have to buffer then entire request/response before it can translate it. So to do this ISA changes the request/response to a chunked encoded response and this way it can translate each packet as a chunk.

In this case this looks like the SQL CE client doesn’t like this and this is the reason why it fails. It’s expecting the response to be in a format with a Content-Length header.

Other devices/components that does content inspection/scanning may potentially do the same, so link translation is not the only one that can cause this to break.

So to avoid the problem as described above, we’ll need to ensure that ISA doesn’t need to translate anything. This means that you cannot change the hostname, ports, paths or e.g. terminate the SSL channel at ISA. So the request through ISA either has to be SSL -> SSL or HTTP -> HTTP using the same hostname and ports as on the outside.

The typical solution here would be to bridge the connection through ISA (SSL->SSL) and ensure that the certificate is the same on the external side of the ISA server as the web published site.

E.g. if you are publishing <https://mail.contoso.com> then we need to ensure that the same request is sent to the Internal server.

On the Web Publishing rule for mail.contoso.com make the following changes:

(Properties of the rule)

- On the To tab, make sure the “This rule applies to this published site:” is set to mail.contoso.com. Please note that this FQDN must match the common name of the certificate installed on the internal server. If it doesn’t you’ll get the error as described in KB 841664:

Clients may receive an "Error Code 500 Internal Server Error" error message when they try to visit a Web site that you publish by using ISA Server 2006 or ISA Server 2004

<https://support.microsoft.com/default.aspx?scid=kb;EN-US;841664>

- On the To tab, make sure the “Forward the original host header instead of the actual one” is ticked.

- On the Bridging tab, make sure that the traffic is not changing ports. E.g. if using SSL -> SSL the “Redirect requests to SSL port” should be set to 443.

- On the Link Translation tab, make sure that “Apply link translation to this rule” is un-ticked.

- In the hosts file (%WINDIR%\SYSTEM32\Drivers\etc\hosts) please ensure that you have an entry for mail.contoso.com that resolves the FQDN to the internal IP address of the published site. E.g. “192.168.0.200 mail.contoso.com”.

The steps below are more to ensure that link translation is not needed:

- On the Path tab, make sure the rule is not configured to translate paths.

This should be enough to prevent the link translation filter in ISA from changing the response to a chunked encoded response. However as I mentioned, there may be other filters that potentially can change the response to a chunked encoded response and that way break the response. This may be 3rd party content and anti-virus filters running in ISA or external to ISA.