Initial requests with custom method (including PATCH) fail with HTTP/2

[MikeEdgar]

HTTP requests using less common methods (including PATCH) fail when using HTTP/2. Requesting with HTTP 1.1 then repeating the request with HTTP/2 resolves the issue.

1. Setup a basic server:
   docker run --rm -d -p 80:9080 -p 443:9443 open-liberty

2. Request using HTTP/2 (may be repeated):
   curl -s -k -X PATCH https://localhost/ -v --http2
   Results in error:
   HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

3. Request using HTTP 1.1 returns server welcome page as expected:
   curl -s -k -X PATCH https://localhost/ -v --http1.1

4. Repeat request using HTTP/2 returns server welcome page as expected.

[wtlucy]

Thanks for reporting this @MikeEdgar - I've spent a few minutes looking over this scenario, as reproducing it is simple. Despite what you've seen when accessing the server welcome page, Liberty doesn't actually currently support PATCH. As you've found, the welcome page is a bit of a special case. If you point curl to a non-welcome-page path, the correct 501 response is returned:

$ curl -s -k -X PATCH https://localhost:9443/testApp/ -v --http1.1
....
> PATCH /testApp/ HTTP/1.1
....
< HTTP/1.1 501 Not Implemented
....
Error 501: Method PATCH is not defined in RFC 2068 and is not supported by the Servlet API

$ curl -s -k -X PATCH https://localhost:9443/testApp/ -v --http2
...
> PATCH /testApp/ HTTP/2
...
< HTTP/2 501
...
Error 501: Method PATCH is not defined in RFC 2068 and is not supported by the Servlet API
* Connection #0 to host localhost left intact

It's not clear to me yet if the welcome page should be returned in the HTTP/1.1 case for an unsupported method. Regardless, the PROTOCOL_ERROR error displayed by curl in the HTTP/2case is not right; we'll look in to that.

[MikeEdgar]

@wtlucy - thanks for following up. I was looking for the simplest way to reproduce the issue using the prepackaged Docker image and just stumbled on using the welcome page. My case involves using JAX-RS 2.1 where PATCH should indeed be supported.

[MikeEdgar]

@wtlucy, I've done a bit of research into the com.ibm.ws.transport.http component and it seems that the behavior I'm seeing with HTTP/1.1 is due to the fact that for that version of the protocol a new instance of com.ibm.wsspi.http.channel.values.MethodValues is generated and stored if not already defined. Requests using HTTP/2 do not create a new instance, but will use an instance already created by a version 1.1 request - which explains the behavior in my example.

A couple things -

1. SHOULD version 1.1 requests automatically create new com.ibm.wsspi.http.channel.values.MethodValues instances? This seems like a potential way for someone to attack the server with illegal HTTP methods and consume memory.

2. It's not clear that the error handling code called from the catch at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest() line 378 is functioning properly for HTTP/2. Based on what I've seen with HTTP/1.1, I do not believe it would ever be executed for that version of the protocol. I believe your example showing a 501 response is occurring further in the request at the Servlet level rather than the transport level. Can you share the details of the testApp you used to produce the 501 errors?

[loriadi]

Hi @MikeEdgar , I think you are on the right track on 2. above. The code is in the middle of deciding if it's H2 or not, and is falling through to the HTTP 1.1 section in this case. I'm looking into it in more detail.

[loriadi]

I've found the issue that caused the HTTP/2 Protocol error and I will use this issue to track the fix.

[loriadi]

Now looking at the inconsistent behavior between HTTP/1.1 and HTTP/2 with a PATCH request and the Liberty landing page.

[loriadi]

I opened a new issue for the behavior difference between HTTP/1.1 and HTTP/2 with PATCH.