3 ms·

And the penalty for being "wrong" is..? You can't write code relying on random third-party code doing what it's "mandated" to do by the standard, because malic

And the penalty for being "wrong" is..? You can't write code relying on random third-party code doing what it's "mandated" to do by the standard, because malicious code exists and so do malicious services. So as a client, if you're connecting to services you don't control, you need to be able to handle misbehaving third-party code. And what it means for a request to be "successful" is entirely at the discretion of the author of the software. I think it's fairly clear that the software looked for a response, found one, and successfully returned it to the client. Which isn't to say that the code is optimal, necessarily, but unless you have a contract to say otherwise then I don't think you've any basis to claim that it must do anything in particular.

shkkmo 3y ago
> I don't think you've any basis to claim that it must do anything in particular. The relevant part of the spec says that returning a 4XX code is a SHOULD [0] not a MUST. That means: > This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course [1] [0] https://www.rfc-editor.org/rfc/rfc9110.html#name-client-error-4xx https://www.rfc-editor.org/rfc/rfc9110.html#name-client-erro... [1] https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 So yes, there is no requirement to return a 4XX message, but you should think carefully and understand the consequences of not doing so. One consequence is creating false positives in most vulnerability scanners. Another consequence is potentially messing up various crawlers, including those that help search engines index your content.
- andrewaylett 3y ago
  In order to conform to the spec, yes. But almost by definition, people who don't care to conform to the spec aren't going to worry overmuch about whether what they're doing is conformant with the spec. As a client, you've got to be ready to deal with non-conformant implementations. As a service owner, there is no authority who will hunt you down for deploying a service that doesn't conform to the spec. Let me restate my claim slightly: acknowledging that impolite to claim to conform to a spec and then not do so, no-one has a right to claim that any arbitrary person must write code that conforms to any arbitrary RFC. > ["MUST",] "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. (my emphasis) I may choose to return whatever response code I want in whatever circumstances I feel like, and there's absolutely nothing you can do to stop me. I probably won't, because that would be silly. But there's no must.
  - shkkmo 3y ago
    > As a client, you've got to be ready to deal with non-conformant implementations The whole point of the "MUST" vs "SHOULD" is that you can assume that you don't have to handle implementations that aren't compliant (e.g. don't do the things they must do to be in compliance) but do need to worry about handling edge-cases where implementations are in compliance but not doing things the way they should. Both tools (the vulnerability scanner and Prometheus) should make changes but I would consider the Prometheus change to be a bug report (which they can clearly choose to not fix and still be compliant) and the vulnerability scanner would be a feature request to check file contents rather than just relying on the status.
    - andrewaylett 3y ago
      Not at all -- the point (in general) of MUST is that as a service owner, you can assume that your implementation won't work properly unless you adhere to the specification. But unless you control all of the implementations you're interacting with, you can't assume that they'll conform. You might well decide to handle non-compliance by declining to continue, but you still need to handle those cases. I don't disagree with your assessment of the changes required to Prometheus or the vulnerability scanner, but I'd rate the Prometheus bug as really low priority, and the feature request for the scanner as a blocker for adoption: it might be correctly behaving as designed, but that doesn't mean the design is useful.

shkkmo 3y ago

> I don't think you've any basis to claim that it must do anything in particular. The relevant part of the spec says that returning a 4XX code is a SHOULD [0] not a MUST. That means: > This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course [1] [0] https://www.rfc-editor.org/rfc/rfc9110.html#name-client-error-4xx https://www.rfc-editor.org/rfc/rfc9110.html#name-client-erro... [1] https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 So yes, there is no requirement to return a 4XX message, but you should think carefully and understand the consequences of not doing so. One consequence is creating false positives in most vulnerability scanners. Another consequence is potentially messing up various crawlers, including those that help search engines index your content.

andrewaylett 3y ago
In order to conform to the spec, yes. But almost by definition, people who don't care to conform to the spec aren't going to worry overmuch about whether what they're doing is conformant with the spec. As a client, you've got to be ready to deal with non-conformant implementations. As a service owner, there is no authority who will hunt you down for deploying a service that doesn't conform to the spec. Let me restate my claim slightly: acknowledging that impolite to claim to conform to a spec and then not do so, no-one has a right to claim that any arbitrary person must write code that conforms to any arbitrary RFC. > ["MUST",] "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. (my emphasis) I may choose to return whatever response code I want in whatever circumstances I feel like, and there's absolutely nothing you can do to stop me. I probably won't, because that would be silly. But there's no must.
- shkkmo 3y ago
  > As a client, you've got to be ready to deal with non-conformant implementations The whole point of the "MUST" vs "SHOULD" is that you can assume that you don't have to handle implementations that aren't compliant (e.g. don't do the things they must do to be in compliance) but do need to worry about handling edge-cases where implementations are in compliance but not doing things the way they should. Both tools (the vulnerability scanner and Prometheus) should make changes but I would consider the Prometheus change to be a bug report (which they can clearly choose to not fix and still be compliant) and the vulnerability scanner would be a feature request to check file contents rather than just relying on the status.
  - andrewaylett 3y ago
    Not at all -- the point (in general) of MUST is that as a service owner, you can assume that your implementation won't work properly unless you adhere to the specification. But unless you control all of the implementations you're interacting with, you can't assume that they'll conform. You might well decide to handle non-compliance by declining to continue, but you still need to handle those cases. I don't disagree with your assessment of the changes required to Prometheus or the vulnerability scanner, but I'd rate the Prometheus bug as really low priority, and the feature request for the scanner as a blocker for adoption: it might be correctly behaving as designed, but that doesn't mean the design is useful.