Missing info in the "Call failed with status code" error message (FlurlHttpException)

[alekdavisintel]

When making a call to the existing endpoint for a non-supported operation (e.g. PATCH), the Message property of the FlurlHttpException has the following format:

Call failed with status code 4xx (): OPERATION endpoint

Is there something supposed to be inside of parentheses? Should it be the text value of the HTTP status code, like:

Call failed with status code 405 (Method Not Allowed): PATCH https://whatever.url

It seems to be the issue with other status calls, as well, not just with 405.

[tmenier]

Hmm. It seems impossible that Flurl is constructing that message. Here's the only line in the entire code base where Flurl builds a message resembling that:

https://github.com/tmenier/Flurl/blob/dev/src/Flurl.Http/FlurlHttpException.cs#L42

Note that call.Response.StatusCode is an integer, so it's virtually impossible for it to render as "4xx" in any scenario. I suspect something on your end is doing it, or intercepting Flurl's message and scrubbing it perhaps?

[alekdavis]

Oh, it's not 4xx, it's the actual HTTP status code value, like 400, 405', etc. In the first message, I just specified the FlurlHttpException message format. The second message is the actual message (with the exception of the endpoint URL, which I made up).

[alekdavis]

I checked the source and it looks like the call.HttpResponseMessage.ReasonPhrase on line 42 is empty:

return $"Call failed with status code {call.Response.StatusCode} ({call.HttpResponseMessage.ReasonPhrase}): {call}";

[alekdavis]

I think I got it. The REST endpoint I'm calling must not be returning the ReasonPhrase, so this property is most likely empty. Maybe it can have a fallback and if the ReasonPhrase is missing, use the corresponding enum value from the HttpStatusCode type. So, instead of:

Call failed with status code 405 (): PATCH https://whatever.url

it would return:

Call failed with status code 405 (MethodNotAllowed): PATCH https://whatever.url

[alekdavis]

I was hoping that we can fix the web server response and return the appropriate reason phrase, but it does not seem to be feasible, since we're using a third party app and we have no control of the server responses. You would not believe the crap that app returns in the response (like, an HTML error page without the closing HTML tag), so I am not surprised that they do not include the reason phrase. And unfortunately, there is nothing we can do to fix it, so if there were a way to either not include empty parentheses or add the default reason value, it would make the error messages in the FlurlHttpException objects a bit better.

[tmenier]

Haha, ok I'll keep this open. I like your idea of falling back on the enum value, should be simple and I'll get it on my near-term radar.