MPWS on Maintenance: No HTTP Status Code specified

[m4rcel]

This is not a major problem, but I want to mention it to you.

As of the current maintenance, the MPWS is of course not available. As I was currently testing something with it, I was a bit irritated, that an Exception was thrown, but that there was no real cause given within their.

So if possible, the MPWS should use either 503 Service unavailable (if detectable as such) or at least 500 Internal Server Error, if the request cannot be executed at all.

[gouxim]

I do agree we lack a practical "maintenance mode" on our infrastructure. Most of the time, deployments don't affect production so we don't need it *that much*.

Today I pushed some big backend changes to prod so I had to shutdown our Web server to work peacefully on the server for a couple hours ; thanksfully that happens rarely.

Thanks for your feedback anyway

[m4rcel]

It is not the problem of a missing maintenance mode itself. What I wanted to report is, that the MPWS-SDK should try to at least return *any* status, which give the information, that its a server fault, not a client one (i.e. 500 or 503).

More detailled: In HTTPClient line 307, the SDK always relies on the status_code returned in the HTTP request. At this point, if the Status-Code is not available, it should use a 500/503 instead of a plain 0.

[gouxim]

I do agree it should return a proper status code. This is why we need a maintenance mode: to show a special page or return a special code on-demand. In this particular case, this morning, first I shutdown the server (= timeout) then I started it but kept the API offline with a Deny apache rule (= 403 code).

However I don't agree the SDK should return 500 if something else was received. It has to be "impartial". I'm trying to understand the behaviour you had: did you have any unexpected code, or return values? Both API Timeout and 403 Responses should be handled well by the SDK at the moment.

[m4rcel]

The SDK threw an Exception with HTTPStatusCode set to 0 (thus HTTPStatusMessage set to an empty string), and the Exception-Message itself set to an empty string, too. So I knew that there was something wrong, but neither who's fault it was (client or server).

[gouxim]

So I guess it was a badly handled timeout. I'll look into it.