Noncompliant Push Response

[jwilm]

Hello,

We have been seeing a lot (10s of thousands) of 200 OK response codes from sending push messages to firefox users. Here's an example response with the location header obfuscated.

"Response { status: 200, version: HTTP/1.1, headers: {"server": "nginx", "date": "Mon, 18 Nov 2024 19:11:00 GMT", "content-length": "0", "ttl": "259200", "vary": "Origin, Access-Control-Request-Method, Access-Control-Request-Headers", "location": "https://updates.push.services.mozilla.com/m/<snip>", "strict-transport-security": "max-age=31536000", "via": "1.1 google", "alt-svc": "h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000"}, body: Body(Empty) }"

Based on the response headers, it seems that nginx might be rewriting the response code.

cc @chamons

┆Issue is synchronized with this Jira Task

[pjenvey]

Could you be more specific about how this response is non-compliant?

[jrconlin]

Thank you. We have identified a bug inside of our code where we return a 200 when messages are handed off to some routers. Since our system can not ensure delivery of a message to the User Agent at this time, we should only return 201 (as per the RFC).

We cannot ensure end-to-end delivery because our system relies on using third party delivery systems for mobile devices which also do not provide this capability.

[jwilm]

Seems like this has already been addressed, but just for posterity wanted to answer this question:

Could you be more specific about how this response is non-compliant?

The push RFC defines only 201 and 202 as valid successful response codes when sending a push message. 201 seems to be the expectation when not requesting receipts.

Thanks all.

[jrconlin]

FWIW, I want to thank you for being one of the very few folk that actually pay attention to the response codes we provide.

[jwilm]

Hah, of course. I'm appreciative with how open the Mozilla push implementation is and how easy it is to provide that feedback in the first place. Thanks for addressing the issue so quickly.