Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using proxy on another machine results in HPE_UNEXPECTED_CONTENT_LENGTH #1488

Closed
Starystars67 opened this issue Jun 10, 2020 · 12 comments
Closed
Labels
Question Question related to the plugin functionality or other
Milestone

Comments

@Starystars67
Copy link

Hey firstly I want to start by saying this is an impressive bit of kit you guys have made here.

So the issue i have found / might be better suited to a question is that I am trying to setup plan behind a proxy server running on a separate server. The two machines are connected via vlan. I can connect to plan using the remote machine IP over vlan and it is using HTTP (due to proxy setting in the ssl settings). I then obviously want to use HTTPS when connecting over the domain name (outside the proxy and vlan) however i keep getting this returned: HPE_UNEXPECTED_CONTENT_LENGTH
Now I setup a small web server to confirm that HTTP traffic is working with the proxy from the remote machine and it is so the issue is with plan from what I can conclude.

Are you able to assist in trying to resolve this?

@Starystars67 Starystars67 added the Question Question related to the plugin functionality or other label Jun 10, 2020
@AuroraLS3
Copy link
Collaborator

According to https://github.com/nodejs/node/blob/8b4af64f50c5e41ce0155716f294c24ccdecad03/deps/http_parser/http_parser.c

The cause may be:

  • Double content-length header
  • Both headers present: chunked encoding & content length

~ sindresorhus/got#646 (comment)

Plan uses Content-Length header, if your proxy adds a Transfer-encoding: chunked or another Content-Length header then that might be causing this issue.

@Starystars67
Copy link
Author

Hey thanks for the reply, This is the error I am getting in the proxy (redbird):
image

Now I am guessing in the dark here but I think this is showing that the issue is in reading the web server? Are you possibly able to offer some advice?

If it helps this is a proxy I have been using for several other sites and services with no issues so far.
Do you have discord perhaps?

@AuroraLS3
Copy link
Collaborator

From their error stacktrace it says addChunk so I'm guessing the proxy is using Transfer-encoding: chunked You might want to try filtering the Content-Length header from Plan responses in your proxy configuration to see if it fixes it.

@Starystars67
Copy link
Author

Im working on that now. Will report back with a result either way.

@AuroraLS3
Copy link
Collaborator

Closing as solved

@skerit
Copy link

skerit commented Nov 25, 2020

I'm also getting this issue since a few versions. I run plenty of other sites behind the proxy that also set content-length though, so I'm not sure where the issue is currently.

@AuroraLS3
Copy link
Collaborator

AuroraLS3 commented Nov 25, 2020

Hi @skerit
Build 791 had one commit that changed how content-length was set for HTTP 204 (No Content) responses. 0ac5ad6

You can test if those responses are the cause by testing with build 770 https://github.com/plan-player-analytics/Plan/releases/tag/5.1.770

If they are caused by that, see what your proxy sends back for a HEAD or OPTIONS response, as those might be the ones causing issues in your case (Assuming it is a new thing from recent changes)

@skerit
Copy link

skerit commented Nov 25, 2020

I don't think that's the issue. I made some requests to the Plan webserver directly (not going through the proxy) with curl, and it most definitely is sending both a content-length and transfer-encoding: chunked header:

curl -i http://localhost:8804/server/Blackblock
HTTP/1.1 200 OK
X-robots-tag: noindex, nofollow
Date: Wed, 25 Nov 2020 11:08:04 GMT
Access-control-allow-methods: GET, OPTIONS
Transfer-encoding: chunked
Content-type: text/html; charset=utf-8
Access-control-allow-origin: *
Access-control-allow-credentials: true
Content-length: 101778
Accept-ranges: bytes

@AuroraLS3
Copy link
Collaborator

I don't unfortunately know what is setting that header on the response as there are no calls in the Plan code to set the transfer-encoding header, nor any implementation for a chunked transfer - but I can see that header on my test setup as well.

I tried to print what headers Plan has set:
image
as seen here, they are not set, but when the response reaches Firefox it has that header
image

So I think that the header is either set by the library I am using as the webserver, or it is inferred by HTTP clients from other properties of the response (I'm unaware what those might be).
Either way it is a bit problematic as I can't probe further into the library or firefox to find out which one it is.

@skerit
Copy link

skerit commented Nov 25, 2020

Hmm, could you maybe manually set it to transfer-encoding: identity? That seems like a very "vanilla" setting, maybe the library would then ignore it?

@AuroraLS3
Copy link
Collaborator

I can try that. Seems like bit more work than just setting it because that requires the content length header and gzip encoded stuff would probably require gzip instead

@AuroraLS3 AuroraLS3 reopened this Nov 25, 2020
@AuroraLS3 AuroraLS3 added this to the 5.2 milestone Jan 19, 2021
@AuroraLS3
Copy link
Collaborator

Ok I found where the chunked transfer encoding is being set https://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpExchange.html#sendResponseHeaders(int,%20long)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question Question related to the plugin functionality or other
Projects
None yet
Development

No branches or pull requests

3 participants