5 ms·
400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't aut
by ants_everywhere 2y ago
400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.
- endofreach 2y agoWell in that case really anything is a 403.
- kijin 2y ago404 would also work, since the resource does not exist at the http: address.
- bruce511 2y agoTrue, but 404 has trained us to look hard at the URL part, not the protocol part. Whereas 403 or 400 are less likely to have so automated built-in handling on the client side.
- mbreese 2y agoBut that also implies that some user would be authorized to make a request to the HTTP port (or that the resource does exist, which in this case it doesn’t). IMO, 400 is more accurate, but really either could be acceptable, so long as the client is notified of the error. But, I wouldn’t automatically redirect the client. That’s what we are trying to avoid.
- ants_everywhere 2y agoGood point. I guess this might depend a little on the implementation. In some cases the http endpoint may exist but may only be accessible to a sidecar container via localhost. For example, if the sidecar terminates https.