HTTP DELETE containing payload or form data results in response 400 'Bad request'

[svendiedrichsen]

Description

---

This is mainly a feature request:

When the payara server is called with HTTP DELETE request containing a payload or form which results in a Content-Length > 0 a HTTP response 400 'Bad request' is returned.

Expected Outcome

Concerning the HTTP 1.1 spec it is undefined what should happen if this occurs but its generally not forbidden. Glassfish/Grizzly has a configuration option which may allow such requests. By default this is deactivated but it would be really nice to have this configuration option in Payara available. The following Glassfish ticket deals with this: https://java.net/jira/browse/GLASSFISH-21238

Current Outcome

Response HTTP 400 will always be returned.

Environment

• Payara Version: 4.1.1.171.1
• Edition: Full
• JDK Version: 1.8.0_121
• Operating System: Mac, Linux

[smillidge]

Fix for GLASSFISH-21238 is already in the Payara code.

It should be configurable via asadmin;

asadmin set configs.config.default-config.network-config.protocols.protocol.http-listener-1.http.allow-payload-for-undefined-http-methods=true

It does need the admin console editing to show it in the admin console.

[svendiedrichsen]

If I'm not mistaken in the comments of GLASSFISH-21238 the dev talks about the fact that it has not been fixed in GF 4.1.1 instead it has been ported back to 4.1.2. Did you cherry pick it for Payara because the issue is in state REOPENDED?

[smillidge]

We regularly keep Payara up to date and did the required cherry pick a while back.

[svendiedrichsen]

Thanks for your time and patience.

[svendiedrichsen]

I'm sorry to reopen this again but when I do the proposed amendments using the asadmin command I receive a 403/Forbidden response doing the DELETE call sending some form params. I have a little WAR prepared to show the problem.

You will find an index.html under /payara.

test-delete-html-1.0-SNAPSHOT.war.zip

I've tested with Payara 4.1.2.172.

[fturizo]

@svendiedrichsen, you are correct. This bug is still present on the current version of Payara Server. I've created the internal issue PAYARA-1791 so the developers can take a look to it.

[fturizo]

Greetings @svendiedrichsen, the developers have tested this behaviour and found no problems with the way the Grizzly HTTP listener is configured. I've tested a sample REST application and got a 204-No Content response after setting the property of the listener. With your test application, I'm indeed getting a 403 - Forbidden. Could you attach the code for your application configuration class and the REST endpoint to give it a look?

[timbrody]

I have recently encountered this issue (DELETE with body) and can confirm that on version 172 and allow-payload-for-undefined-http-methods set to true Payara passes the request through to the Web app.

For the benefit of others, ensure allow-payload-for-undefined-http-methods is set on the http listener actually in use - the example from @smillidge is for setting the default config.

e.g. for my server the setting is

set configs.config.server-config.network-config.protocols.protocol.http-protocol.http.allow-payload-for-undefined-http-methods=true

          <protocol name="http-protocol">
            <http xpowered-by="false" allow-payload-for-undefined-http-methods="true" default-virtual-server="server">
              <file-cache></file-cache>
            </http>
          </protocol>

[fturizo]

Considering that we haven't received a reply for @svendiedrichsen and the behaviour of the Grizzly option is working as intended we'll close the issue for the moment.