Unexpected HTTP 4XX in case of server issue

[DefteZ]

Hello,

Page: /navigator/ IMHO It is better to have HTTP 5XX answer to frontend (for example 500) if search back-end answered with HTTP 401. Now: back-end answers with HTTP 404/400. But client request can be fully valid, it is just issue with server config for example.

[amotl]

Dear Andrii,

thanks for notifying us about a potential anomaly or a way to improve on the response code side. We are aware that there's room for improvements all over the place.

May we humbly ask about a minimal example how to reproduce the specific case you are mentioning? As http://localhost:6543/navigator/ is the main entrypoint when running in development mode, I figure it would only be available or not, so there's no doubt about any response code at all.

As you are mentioning the search back-end, I figure you might be talking about the data source API entrypoints like http://localhost:6543/api/ops/published-data/search?expression=pn=EP666666 for OPS?

If this is true, can you point out the specific data source API where things might go wrong or can be improved?

Thanks already and with kind regards, Andreas.

[DefteZ]

Hello,

When access token is missed in config OPS request return HTTP401 and then patzilla return HTTP 400.

But it is definitely server issue and it should be HTTP 5XX

[amotl]

Dear Andrii,

thanks for getting back on this and reporting about the context of the request you have been referring to.

TLDR;

If this request is failing due to an authorization issue, we should probably forward the 401 Unauthorized response status to the user then, right? This might give the client a clue about what's actually going on - otherwise, it won't be able to tell anything about the real reason the request is failing.

Thoughts

I believe this detail can be argued about as - while the request definitively is issued by the server - it might not be a server error per se. So, either we might think about sending 502 Bad Gateway downstream or we just keep the 401 Unauthorized response status in order to signal this to the user appropriately.

Please recognize that OPS credentials might also come from the users' personal settings so this request can fail independently of the server-configured OPS credentials.

Rationale

I believe it can well be argued that the server is making the request on behalf of the user, essentially boiling down to be acting as a proxy in this very context. So, it might actually be valid to forward the response code 1:1 when looking at this from another perspective.

So, what do you think about just forwarding 401 Unauthorized verbatim without amending the response status at all?

With kind regards, Andreas.

[DefteZ]

Please recognize that OPS credentials might also come from the users' personal settings so this request can fail independently of the server-configured OPS credentials.

Yes, I missed this. It makes the case not so obvious and I don't have single answer anymore.

Because there is user authentication itself at Patzilla, answer with HTTP401 it case of OPS credentials issue can obscure, because request already has right authentication.

RFC 7231 say that :

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

So, in case of user-configured OPS I think that HTTP400 looks suitable (or 403 maybe)

But for server-side credentials it is definitely HTTP500 (anyway 5xx)

[amotl]

Dear Andrii,

Because there is user authentication itself at Patzilla, answer with HTTP401 it case of OPS credentials issue can obscure, because request already has right authentication.

I see you your point. Let's make the case here to be able to differentiate the response in order to kick the user to a login screen based on the outcome of the HTTP status like "401 => login screen"?

So, in case of user-configured OPS I think that HTTP400 looks suitable (or 403 maybe) But for server-side credentials it is definitely HTTP500 (anyway 5xx)

I believe your arguments are valid but nevertheless I'm hesitant to implement different response status for signalling essentially the same thing under different conditions. That would increase the mental load on each API consumer - human or machine.

---

Thanks for bringing up 403 Forbidden.

Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.” -- https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/6937030#6937030

401 is Authentication error, 403 is Authorization error. Simple as that. -- https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/6937030#comment22150433_6937030

As these arguments resonate well with me, I'd vote for passing 403 Forbidden to the client in all cases where the user might have been authenticated to PatZilla but does not have the appropriate permissions to access any upstream resources where PatZilla is an intermediary to, API-wise.

What to you think?

With kind regards, Andreas.

[DefteZ]

I see you your point. Let's make the case here to be able to differentiate the response in order to kick the user to a login screen based on the outcome of the HTTP status like "401 => login screen"?

Yes, 401 means like "login and try again"

As these arguments resonate well with me, I'd vote for passing 403 Forbidden to the client in all cases where the user might have been authenticated to PatZilla but does not have the appropriate permissions to access any upstream resources where PatZilla is an intermediary to, API-wise.

What to you think?

I think that 403 is a good choice here :)