core-wg / corrclar

Corrections and Clarifications to CoRE standards
Other
0 stars 0 forks source link

RFC7959 - blockwise for error responses? #25

Open boaks opened 2 years ago

boaks commented 2 years ago

I currently hit a "very special case".

A coap2http proxy receives an http error (404) and a page with about 2k.

If the 404 is translated into 4.04, "my stack" (Eclipse/Californum) refuses to do that as blockwise transfer.

So, are error responses considered to be transferred with blockwise with block2? I didn't found something in RFC7959, but maybe I overseen it.

boaks commented 2 years ago

I found an answer in issue core-wg/corrclar#21.

The resulting question will be, if it's not possible, to have a blockwise error-response, what is then considered to be the payload in that proxy use-case?

chrysn commented 2 years ago

On Tue, Sep 06, 2022 at 06:05:13AM -0700, Achim Kraus wrote:

The resulting question will be, if it's not possible, to have a blockwise error-response, what is then considered to be the payload in that proxy use-case?

I agree that blockwise on error responses is just not possible.

The best suggestion I can give is to turn the HTTP 4xx response into problem-details document (RFC-to-be 9290), and return that on a successful 2.05 Content code. I'm not sure though how that'd be best distringuished from a genuine HTTP 200 OK document of the same data (for a general-purpose proxy), and whether it needs to be distinguished from that in the first place.

mrdeep1 commented 2 years ago

The data in a HTTP 404 response in my experience is used to give some clues (with marginal benefit, but looks pretty) as to why the server had to generate a 404 error, but is really down to the page is not available. Thus, dropping the data provided in the HTTP response is no great loss from my point of view.

However, if the CoAP is going to be converted back to html in a downstream proxy it would be nice to have some basic html in the 4.04 CoAP response body that is used to state the obvious. So, perhaps on converting from html to CoAP instead of dropping all the html that is too large, a simple piece of basic html is used instead otherwise the downstream proxy will need some smarts to build a 404 response page - which is unlikely.

boaks commented 2 years ago

Thanks both for your feedback. I don't think, it pays off to support http-coap-http. I guess, I try to check, if it's html, and then try to grab the <body>, otherwise just truncate it.