HDDS-13168. Fix error response format in CheckUploadContentTypeFilter

[unknowntpo]

What changes were proposed in this pull request?

HDDS-13168. Fix content type error response format in CheckUploadContentTypeFilter.java

The CheckUploadContentTypeFilter was modified to return properly formatted JSON error responses instead of using the generic sendError() method. When a data upload request lacks the required application/octet-stream content-type, the filter now returns a consistent JSON error response with the correct application/json content-type header.

This change ensures API consistency across all WebHDFS endpoints and makes error responses easier for clients to parse programmatically. Previously, error responses from this filter were not properly formatted as JSON, creating inconsistency with other API responses.

The specific changes include:

• Replaced the sendError() call with a proper JSON response construction
• Set appropriate HTTP status code (400 Bad Request)
• Ensured the response content-type is application/json;charset=utf-8
• Maintained the same error message content for backward compatibility.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-13168

How was this patch tested?

1. Build distribution

mvn clean package -DskipTests=true

2. Run docker compose

cd ./hadoop-ozone/dist/target/ozone-2.1.0-SNAPSHOT/compose/ozone
OZONE_DATANODES=3 ./run.sh -d

3. Create a file called test.txt in the local directory

echo 'hello world' > export.txt

4. Send request without content-type

curl -v -X PUT -T ./export.txt "http://localhost:14000/webhdfs/v1/exports/text/export.txt?op=CREATE&data=true&user.name=hadoop"

5. Verify that response code is Bad Request (400), and the error message is:

and the response will be:

curl -v -X PUT -T ./test.txt  "http://localhost:14000/webhdfs/v1/exports/text/export.txt?op=CREATE&data=true&user.name=hadoop"
Note: Unnecessary use of -X or --request, PUT is already inferred.
* Host localhost:14000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:14000...
* Connected to localhost (::1) port 14000
> PUT /webhdfs/v1/exports/text/export.txt?op=CREATE&data=true&user.name=hadoop HTTP/1.1
> Host: localhost:14000
> User-Agent: curl/8.7.1
> Accept: */*
> Content-Length: 12
> 
* upload completely sent off: 12 bytes
< HTTP/1.1 400 Bad Request
< Date: Thu, 12 Jun 2025 15:33:13 GMT
< Cache-Control: no-cache
< Expires: Thu, 12 Jun 2025 15:33:13 GMT
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Set-Cookie: hadoop.auth="u=hadoop&p=hadoop&t=simple-dt&e=1749778393435&s=qrnNFoyNNWT+lE4tzPx6ke2XMpGUUH4Eb7W13zdodYQ="; Path=/; HttpOnly
< Content-Type: application/json;charset=utf-8
< Transfer-Encoding: chunked
< 
* Connection #0 to host localhost left intact
{"error":"Data upload requests must have content-type set to 'application/octet-stream'"}

Which has status code Bad Request (400) and JSON response will be:

{"error":"Data upload requests must have content-type set to 'application/octet-stream'"}

6. Now, send request with content-type set to application/octet-stream

curl -v -X PUT -T ./export.txt -H"Content-Type: application/octet-stream" "http://localhost:14000/webhdfs/v1/exports/text/export.txt?op=CREATE&data=true&user.name=hadoop"

and the response code will be 201

Note: Unnecessary use of -X or --request, PUT is already inferred.
* Host localhost:14000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:14000...
* Connected to localhost (::1) port 14000
> PUT /webhdfs/v1/exports/text/export.txt?op=CREATE&data=true&user.name=hadoop HTTP/1.1
> Host: localhost:14000
> User-Agent: curl/8.7.1
> Accept: */*
> Content-Type: application/octet-stream
> Content-Length: 12
> 
* upload completely sent off: 12 bytes
< HTTP/1.1 201 Created
< Date: Thu, 12 Jun 2025 15:30:48 GMT
< Cache-Control: no-cache
< Expires: Thu, 12 Jun 2025 15:30:48 GMT
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Set-Cookie: hadoop.auth="u=hadoop&p=hadoop&t=simple-dt&e=1749778248717&s=m66Bktyw7AXq6xuDt64EdpF9llvWFGAt7tx0K64Fmd8="; Path=/; HttpOnly
< Location: http://localhost:14000/webhdfs/v1/exports/text/export.txt
< Content-Type: application/json
< Content-Length: 72
< 
* Connection #0 to host localhost left intact
{"Location":"http://localhost:14000/webhdfs/v1/exports/text/export.txt"}

Which has status code Created (201) and JSON response will be:

{"Location":"http://localhost:14000/webhdfs/v1/exports/text/export.txt"}

[unknowntpo]

@peterxcli Would you like to review this PR?

[peterxcli]

Thanks @unknowntpo for this quick patch!

And since current way is quite verbose, we can have add a utility to do this for other sendError calls in follow-up. (I guess the others get the same issue which the message we set for them doesnt show in the response.

@unknowntpo @adoroszlai WDYT?

[unknowntpo]

Thanks @unknowntpo for this quick patch!

And since current way is quite verbose, we can have add a utility to do this for other sendError calls in follow-up. (I guess the others get the same issue which the message we set for them doesnt show in the response.

@unknowntpo @adoroszlai WDYT?

Agree, and in order to give user consistent style of response, we may also need to define a response model, specify the schema of the response JSON object.

[jojochuang]

Please consider using a utility library to craft JSON output, for example, Jackson:

import com.fasterxml.jackson.databind.ObjectMapper;
import java.util.HashMap;
import java.util.Map;

Map<String, String> errorMap = new HashMap<>();
errorMap.put("error", errorMessage);

ObjectMapper mapper = new ObjectMapper();
String jsonResponse = mapper.writeValueAsString(errorMap);

PrintWriter writer = httpRes.getWriter();
writer.write(jsonResponse);

[unknowntpo]

I use JsonUtil to do this, which use Jackson under the hood.

[adoroszlai]

Thanks @unknowntpo for the patch, @jojochuang, @peterxcli for the review.

And since current way is quite verbose, we can have add a utility to do this for other sendError calls in follow-up. (I guess the others get the same issue which the message we set for them doesnt show in the response.

@peterxcli can you please file a task for that?

[peterxcli]

Done. https://issues.apache.org/jira/browse/HDDS-13258.