unexpected status 404 with statusLine:HTTP/1.0 404 Not Found

[Former user]

While hitting the web socket sampler with wss protocal, we have received the status code of 404 and its showing the *HTTP/1.0 version*. While hitting the same request using https sampler we got HTTP/1.1 version. could you please assist me in resolving HTTP version issue in Jmeter 5.4.1 We are unable to make a connection due to that HTTP version error , we are getting in Sampler error in view result tree. please find the below attached img

[Peter Doornbosch]

I don’t know why your server answers with HTTP/1.0. It’s probably because it does not support websocket on the given path, that’s why it is returning 404 (which means: not found).

The plugin uses HTTP/1.1, which is also mandated by the websocket specification.

You should focus on the 404, not on the HTTP/1.0

[Milamber]

@peter the root cause for this issue is the Host header send with “:port” on some specific webserver. the webserver (like IIS) doesn’t find the correct virtual host. (and the port ins’t really need because the socket (ip+port) has already connected)

I’ve fixed this same issue on my setup by removing the string concatenation with port in WebSocketClient.java line 172

Before:

            httpWriter.print("Host: " + connectUrl.getHost() + ":" + connectUrl.getPort() + NEW_LINE);
            log.debug(    ">> Host: " + connectUrl.getHost() + ":" + connectUrl.getPort());

‌

After :

           httpWriter.print("Host: " + connectUrl.getHost() + NEW_LINE);
            log.debug(    ">> Host: " + connectUrl.getHost());

‌

[Peter Doornbosch]

No it’s not. Didn’t you read my previous comment?

“The plugin uses HTTP/1.1, which is also mandated by the websocket specification.” (and re-read the description / title of this issue again: it’s about a server replying with HTTP/1.0).

If you have a server that does not accept the port number in the Host header, then

• that’s a different issue
• you server is wrong, see https://www.rfc-editor.org/rfc/rfc9110.html#name-host-and-authority. The fact that the port is optional does not mean you have to omit it when using a default port

But i can hardly believe it that a server would not accept a port number in the Host header. I think it’s more likely that you made a mistake in your testplan by specifying an incorrect port number and that it seems solved by removing the port number.

And finally, your “fix” would make it impossible for people to test with a server that runs on a different (not default) port.

‌

[Milamber]

Hi, my webserver accept the port number in Host header, but my webserver don’t recognize the good virtual host in his configuration because the port is specify on the Host header (the issue is on the webserver, not on your plugin), so the webserver send a 404 error code (probably it’s choice the default virtual host).

My fix works for my case, I just want help you and users of your plugin, to understand this case (404 code with the plugin but works with a browser). The browsers don’t send the port number in host header if it’s the default port (80/443).

I suppose that would be better to add an option/behavior to send or not the port, specially if it’s the default value (or like JMeter, if not port value in sampler, send host header without port).

[Peter Doornbosch]

I appreciate the fact that you want to help, but the point i’m trying to make is that what you describe is just a possible reason for getting a 404 (and certainly not the reason for this particular issue that relates to using HTTP 1.0). In general, other reasons (like pointing to a non-ws resource of using query parameters the server doesn’t like) will be more likely, so presenting your fix as the solution (which is my perception of what you did by adding to this issue and refering to this comment in several other issues regarding 404) can point people in the wrong direction.

What you suggest might be an improvement on the plugin, but please create a new issue for it, so we can distinghuish between this curious behaviour of the webserver you are using and other cases of the 404 problem.