4 ms·

The problem is that we have a culture of accepting mangled requests on the web. This happens in application code too - because web developers are sloppy it's co

The problem is that we have a culture of accepting mangled requests on the web. This happens in application code too - because web developers are sloppy it's common to either disable or not use strict input validation. In a pure .Net world it's the norm to use strict input validation and tell clients to fix their bad requests and this looks like one of those cultural blindspots. "We" wouldn't naturally consider a case where a server accepted a request which has not been strictly validated. With the move to .Net Core and a broadening of the scope to not only target enterprises and we'll find issues like this....

jen20 1y ago
I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers. Mostly this stuff comes down to skill issues.
- PantaloonFlames 1y ago
  If I transmit SOAP or JSONRPC over http, both of which use the response payload itself to contain whether the request was an error or not, what should the status be in case of error ? I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.
  - jen20 1y ago
    > over http > what should the status be in case of error 400 to 500 range status code. You can't ignore the lower level protocol because you're implementing a higher level one.
- j_w 1y ago
  At one point I interacted with an API that would return 200 for every condition, but with a "status" field that would have "OK" or "error", except on some browsers where it would use "OKAY" instead of "OK".
immibis 1y ago
We have to accept mangled requests when there are clients out there that send mangled requests, which they will continue to do as long as servers accept them. Postel's law was good for prototyping but created a security nightmare in production.
- sfn42 1y ago
  First you create an API, then others start using it. So if you never allow mangled requests your clients will necessarily send proper requests. If you're maintaining an old api you can publish new versions of endpoints that don't accept mangled requests. If it's important you can give clients a time limit like let's say a few months to update their software to use your updated endpoints before you remove the old ones.

jen20 1y ago

I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers. Mostly this stuff comes down to skill issues.

PantaloonFlames 1y ago
If I transmit SOAP or JSONRPC over http, both of which use the response payload itself to contain whether the request was an error or not, what should the status be in case of error ? I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.
- jen20 1y ago
  > over http > what should the status be in case of error 400 to 500 range status code. You can't ignore the lower level protocol because you're implementing a higher level one.
j_w 1y ago
At one point I interacted with an API that would return 200 for every condition, but with a "status" field that would have "OK" or "error", except on some browsers where it would use "OKAY" instead of "OK".

immibis 1y ago

We have to accept mangled requests when there are clients out there that send mangled requests, which they will continue to do as long as servers accept them. Postel's law was good for prototyping but created a security nightmare in production.

sfn42 1y ago
First you create an API, then others start using it. So if you never allow mangled requests your clients will necessarily send proper requests. If you're maintaining an old api you can publish new versions of endpoints that don't accept mangled requests. If it's important you can give clients a time limit like let's say a few months to update their software to use your updated endpoints before you remove the old ones.