Aggregate should not add Location header to HTTP 204 responses

[ggalmazor]

Problem description

Aggregate adds Location header to HTTP 204 responses, which is not a standard practice and can confuse clients into thinking that they need to do a redirect.

Steps to reproduce the problem

Here's one method to trigger this:

• Configure Aggregate's hostname in security.properties to your computer's LAN IP address
• Access Aggregate using localhost or your loopback 127.0.0.1 address

Expected behavior

No Location header should be present in 204 responses.

Other information

N/A

[yanokwa]

There might be a good reason for this. I vaguely remember something about supporting coffee shop Wi-Fi login pages? I would dig in into Aggregate's history before making this.

[ggalmazor]

I've learned that 201 responses can use the optional Location header to show the URI of a newly created server-side object, which it's what's happening here. If no Location header is added to the response, the effective request URI should be considered as the object's URL

Although this behavior is conforming to the HTTP standard, Aggregate already has an API with an endpoint to download objects which doesn't match the "effective request URI" and makes adding a Location header the only reasonable option.

In any case, we could make this issue about veryfing that we put the correct API endpoint in the Location header, but I don't see much value on doing that at this point. What do you think?