3 ms·
Could be, but there’s a reason to want cachable, proxyable errors here: they’re often very expensive for the origin.
by brians 7y ago
Could be, but there’s a reason to want cachable, proxyable errors here: they’re often very expensive for the origin.
- ktpsns 7y agoActualy, handling an error should be cheaper then handling a proper request. Just because an error most likely means an early exit of the handling server -- which means less time-to-answer, i.e. cheaper. (This does not cover any kind of DoS attack, which is always difficult to handle, regardless of an error or non-error answer) However, effectively we agree with derefr, saying that HTTP status code design did not have this pecularity of cachable vs. non-cachable errors in mind. This is definetly a shortcoming.