Hi Holger, It is probably not a good idea to be too strict here. I committed the following to #bleedingEdge === Name: Zinc-HTTP-SvenVanCaekenberghe.465 Author: SvenVanCaekenberghe Time: 18 August 2017, 2:11:25.092807 pm UUID: da9ed1c3-6713-0d00-bd88-7a0d0e6057cd Ancestors: Zinc-HTTP-SvenVanCaekenberghe.464 Allow for non-standard, not-predefined HTTP status line codes as long as they are between 100 and 599 === Name: Zinc-Tests-SvenVanCaekenberghe.240 Author: SvenVanCaekenberghe Time: 18 August 2017, 2:11:44.677301 pm UUID: ad74fcc4-6713-0d00-bd89-fc2d0e6057cd Ancestors: Zinc-Tests-SvenVanCaekenberghe.239 Allow for non-standard, not-predefined HTTP status line codes as long as they are between 100 and 599 === Sven

On 18 Aug 2017, at 11:44, Holger Freyther <holger@freyther.de> wrote:

Hi,

I am currently using ZnClient to fetch data from a service behind "cloudflare" and sometimes the real/origin backend is unreachable/fails. Cloudflare has added additional[1] 5XX codes and ZnStatusLine>>#code: will signal an ZnUnknownHttpStatusCode because of that.

I wonder how ZnClient should deal with these errors? IIRC the HTTP RFC specifies error classes and without knowing what "525" means one can know that the request was not successful and that the server is at "fault"?

Should ZnStatusLine handle an unknown code gracefully? E.g. >>#reason: seems to do that already?

have a nice weekend

holger

[1] https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#Cloudflare