Bug Description
Briefly describe the bug/issue you've encountered.
The file /internal/api/handler/parsers.go performs a match against incoming ContentType header. However it does overly strict matching.
.
.
switch contentType {
case echo.MIMETextPlain:
.
.
In the above, "echo.MIMETextPlain" is defined as MIMETextPlain = "text/plain". Many HTTP client libraries by default generate ContentType headers of the form ContentType: text/plain; charset=UTF-8.
This causes Http client libraries that by default add in the charset parameter to fail with an error. I had to read the Arc source to see what the expected/allowed content-types were.
Steps to Reproduce
- Step 1
Attempt to submit a transaction to /tx endpoint via POST, and set the ContentType header to ContentType: text/plain; charset=UTF-8, or ContentType: application/json; charset=UTF-8
Expected Behavior
The transaction should be processed as normal
Actual Behavior
The transaction is rejected even if it is valid, and a content-type error is returned in the HTTP response.
Bug Description
Briefly describe the bug/issue you've encountered.
The file /internal/api/handler/parsers.go performs a match against incoming ContentType header. However it does overly strict matching.
In the above, "echo.MIMETextPlain" is defined as
MIMETextPlain = "text/plain". Many HTTP client libraries by default generate ContentType headers of the formContentType: text/plain; charset=UTF-8.This causes Http client libraries that by default add in the charset parameter to fail with an error. I had to read the Arc source to see what the expected/allowed content-types were.
Steps to Reproduce
Attempt to submit a transaction to /tx endpoint via POST, and set the ContentType header to
ContentType: text/plain; charset=UTF-8, orContentType: application/json; charset=UTF-8Expected Behavior
The transaction should be processed as normal
Actual Behavior
The transaction is rejected even if it is valid, and a content-type error is returned in the HTTP response.