While looking into something else, I noticed in my server logs (nginx sits in front of my instance) that a lot of requests made to the webhook were returning a status of 499. In a reverse-proxy situation, that's nginx-speak for "upstream closed the request without a response". plex-pushover should probably return something, even if it's just a message saying "Unsupported event type".
I'm mulling over the potentially appropriate status codes for this case. 501 Not Implemented seems good, since the server won't be acting on unrecognized/unhandled events. Alternatively, 204 No Content could work (but could be construed as implying success when there has been none). Finally, a 4xx code like 415 Unsupported Media Type or just plain 400 Bad Request is possible, but a "client error" code should probably only be sent if the webhook is POSTed a request that can't be recognized as a Plex payload at all (i.e. not an unhandled Plex event type, but a non-Plex event).
While looking into something else, I noticed in my server logs (nginx sits in front of my instance) that a lot of requests made to the webhook were returning a status of
499
. In a reverse-proxy situation, that's nginx-speak for "upstream closed the request without a response". plex-pushover should probably return something, even if it's just a message saying "Unsupported event type".I'm mulling over the potentially appropriate status codes for this case.
501 Not Implemented
seems good, since the server won't be acting on unrecognized/unhandled events. Alternatively,204 No Content
could work (but could be construed as implying success when there has been none). Finally, a 4xx code like415 Unsupported Media Type
or just plain400 Bad Request
is possible, but a "client error" code should probably only be sent if the webhook is POSTed a request that can't be recognized as a Plex payload at all (i.e. not an unhandled Plex event type, but a non-Plex event).