consider defining `error` in terms of RFC 9209

[lukewagner]

There is a TODO to properly fill in the error enum since there's nothing we can simply point to in the HTTP Semantics spec like we do for pretty much the rest of wasi:http/types. At the moment it's just a totally ad hoc collection of cases, which doesn't feel great. @acfoltzer pointed out that the Error Types section of RFC 9209 could be a useful implementation-neutral standards basis for defining the error cases, so I'd like to consider doing that or hear if anyone else has any better ideas.

[PiotrSikora]

I'm glad that RFC 9209 is being used, but you should probably refer to the IANA registry for HTTP Proxy Error Types directly to account for future error types.

Also, keep in mind that it's not a "complete" solution, because http_request_error piggy-backs on the existing HTTP status codes instead of redefining them as standalone error types (unfortunately, I lost that battle at IETF).

[acfoltzer]

Also, keep in mind that it's not a "complete" solution, because http_request_error piggy-backs on the existing HTTP status codes instead of redefining them as standalone error types (unfortunately, I lost that battle at IETF).

@PiotrSikora wouldn't failures of that type be reflected in wasi-http as an "ok" result with the appropriate 4xx/5xx status? Are there applications where it would be useful to have status codes in error?

[PiotrSikora]

@PiotrSikora wouldn't failures of that type be reflected in wasi-http as an "ok" result with the appropriate 4xx/5xx status?

No, local errors shouldn't be mimicked as fake responses with status codes, otherwise you cannot distinguish WASI errors from real errors received from the remote.

Are there applications where it would be useful to have status codes in error?

It's not about having status codes in errors. My point was that there is a whole set of errors missing from that registry, because the HTTP working group didn't want to duplicate those that already had a defined HTTP status code.

e.g. when dispatching a new request with payload above the host's configured size limits, host might want to reject the call with "payload too large" or similar error, but that's not available in the HTTP Proxy Error Types because 413 Payload Too Large already exists.

[lukewagner]

Ah hah, thanks for explaining the background; I think I understand the situation a little better. So then to fill in my understanding a bit better: is the expectation that errors are only returned for errors that occur "in between" the client and remote, whereas the remote always signals failure by an ok result containing a response with an error status-code?

[PiotrSikora]

So then to fill in my understanding a bit better: is the expectation that errors are only returned for errors that occur "in between" the client and remote,

Yes, Proxy-Status errors are emitted only by proxies and other intermediaries in the Proxy-Status header as part of the HTTP response.

Client applications can return errors via different means (stdout, pop-up alert, etc.), so they don't need to do it at the HTTP layer, and a lot of those errors can happen before HTTP request can be even dispatched.

whereas the remote always signals failure by an ok result containing a response with an error status-code?

That's probably not the most appropriate description, since it's mixing layers.

The only way you receive anything from the remote is via HTTP response with appropriate status code and headers, so the ok is returned from the transport layer and not HTTP.

Hope this helps!

[lukewagner]

Great, thanks for the clarifications!