Removing the Content-Length header breaks HEAD requests

[elazarl]

Removing the Content-Length header breaks HEAD requests

[elazarl]

Thanks,

Glad to receive your feedback, and do let me know of any more issues.

This is definitely a bug I didn't think of.

I'll fix it next week. I'll be happy to know if it works for you.

But shouldn't adding something like "if req.Method != "HEAD" {
req.Header.Del('Content-Length") }" will solve the problem completely?

On Fri, Jun 28, 2013 at 11:31 AM, JamesBielby [email protected]:

Hi,

We've started using your proxy as the basis of an internal proxy server
and I have found a bug. The proxy deletes the Content-Length header on all
responses on the basis that the http library should be able to work it out
again from the body, however HEAD requests do contain the Content-Length
header but do not contain the body so the library cannot determine the
correct Content-Length in this case.

In our copy I have just removed this line and that works for the way we
are using the library but I can see that would not be ideal in all
scenarios.

You can reproduce this by using Windows Update with the proxy (which uses
HEAD requests).

Thanks,
James

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11
.

[JamesBielby]

That certainly sounds reasonable.

On 28 June 2013 09:39, Elazar Leibovich [email protected] wrote:

Thanks,

Glad to receive your feedback, and do let me know of any more issues.

This is definitely a bug I didn't think of.

I'll fix it next week. I'll be happy to

But shouldn't adding something like "if req.Method != "HEAD" {
req.Header.Del('Content-Length") }" will solve the problem completely?

On Fri, Jun 28, 2013 at 11:31 AM, JamesBielby [email protected]:

Hi,

We've started using your proxy as the basis of an internal proxy server
and I have found a bug. The proxy deletes the Content-Length header on
all
responses on the basis that the http library should be able to work it
out
again from the body, however HEAD requests do contain the Content-Length
header but do not contain the body so the library cannot determine the
correct Content-Length in this case.

In our copy I have just removed this line and that works for the way we
are using the library but I can see that would not be ideal in all
scenarios.

You can reproduce this by using Windows Update with the proxy (which
uses
HEAD requests).

Thanks,
James

—
Reply to this email directly or view it on GitHub<
https://github.com/elazarl/goproxy/issues/11>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-20176622
.

[chancancode]

Thanks for the fix! It mostly works now, when the content-type is text/html. (I couldn't get the UrlIs filter to work with HTTPS, but other stuff like ContentTypeIs and DstHostIs works.)

However, I have an application/x-javascript file that I'm tampering the body, and it doesn't work.

One of these two things would happen:

Case 1. The server didn't send any response headers, but prepended these to the response body:

0

HTTP/1.0 200 OK
Accept-Ranges: bytes
Age: 1082
Cache-Control: max-age=315360000
Connection: keep-alive
Content-Length: 685580
Content-Type: application/x-javascript
Date: Wed, 03 Jul 2013 23:24:56 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Last-Modified: Fri, 28 Jun 2013 17:30:08 GMT
Server: nginx
Transfer-Encoding: chunked
Vary: Accept-Encoding
Via: 1.0 4e181fe94ccef6b90a51121fd522cf07.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 1KQu6HedzBf1NkS15WCAAsF4SZAi74VDVkux9GzBjZqqZaENHK6NmQ==
X-Cache: Hit from cloudfront

8000
// Actual respinse body begins here

In this case, the browser just keeps spinning and wait for the end on the response indefinitely.

Case 2. The server sends the response headers correctly, prepended this to my response body:

8000
// Actual respinse body begins here

I'm not 100% sure if this is due to the content type or if it's something specific to this particular file. Either way, it looks like goproxy is inserting some newlines where it's not supposed to and causing the response to break.

[chancancode]

Oops. I meant to attach this to #9. I can also open a new issue if you think it's unrelated to #9.