Email signup is one of the features on my website. User initiates POST request which bypasses knot.x completely. The response contains ESI markup, so CDN triggers sub-requests, which go via knot.x instance. knot.x returns 500 for each subrequest call.
This situation doesn't happen when the entire flow starts with GET request.
Here's a diagram with end-to-end HTTP flow:
Steps to reproduce
Send a POST request with Content-Type: application/x-www-form-urlencoded header
Make sure response contains ESI markup
ESI sub-requests should go via knot.x (they inherit request headers from original request - only those that came from the user, Content-Type is one of them)
Each ESI call ends with 500 response
Response headers:
HTTP/1.1 500 java.nio.file.AccessDeniedException: /file-uploads
Content-Type: text/html
Connection: close
Content-Length: 9372
ESI calls are regular GET requests. The only difference in comparison to other situations is the fact that sub-requests inherit parent request headers, so CDN sends GET with Content-Type: application/x-www-form-urlencoded.
knot.x should either reject such request with 400 status code or ignore Content-Type header sent with GET request, as it doesn't make any sense.
Screenshots
N/A
Additional context
The following curl command was enough to reproduce the problem:
Bug description
knot.x version:
1.4.0
Email signup is one of the features on my website. User initiates
POST
request which bypasses knot.x completely. The response contains ESI markup, so CDN triggers sub-requests, which go via knot.x instance. knot.x returns 500 for each subrequest call.This situation doesn't happen when the entire flow starts with
GET
request.Here's a diagram with end-to-end HTTP flow:
Steps to reproduce
POST
request withContent-Type: application/x-www-form-urlencoded
headerContent-Type
is one of them)Response headers:
Response body:
Expected behavior
ESI calls are regular
GET
requests. The only difference in comparison to other situations is the fact that sub-requests inherit parent request headers, so CDN sendsGET
withContent-Type: application/x-www-form-urlencoded
.knot.x should either reject such request with 400 status code or ignore
Content-Type
header sent withGET
request, as it doesn't make any sense.Screenshots
N/A
Additional context
The following
curl
command was enough to reproduce the problem:Those 500s are visible in
knotx-access.log
file, butknotx.log
stays empty despite of the fact I increased log level toDEBUG
.It could be related to #321
Possible workaround - "sanitize" HTTP request before it gets processed by knot.x and remove
Content-Type
fromGET
requests.