I’m trying to get a response header from a POST using the HTTPUtils PostStringToURL when it returns a 429, but it seems to throw an exception leaving me without access to the headers.
If the service at http://example.com/test returns a 200, I do get the header, but when 429 is returned an exception is thrown and no header is obtained.
I think there might be a an order issue, I believe you are getting a 429 in the response filter, but yes the PostStringToUrl is still throwing an exception which is the designed behavior since it uses the HttpClient response EnsureSuccessStatusCode method. The responseFilter is invoked before this happens, so you can read the header. For example, a client will run code very similar to yours:
If you can create a reproduction on GitHub I can take a closer look. Also to sanity test against just not having any value in the Retry-After header, can you log something unique in the responseFilter action?
If you can create a reproduction on GitHub I can take a closer look.
Will do. I’m travelling interstate for the next 10 days so it might take me about that long to pull that together if I can’t get it done in the next few minutes.
URL.PostStringToUrl("{}", responseFilter: res =>
{
retryAfterResponseHeader = res.GetHeader("Retry-After");
Console.WriteLine(Guid.NewGuid().ToString());
});
Probably nothing, but that will more ensure order of events.
No worries, wouldn’t be needed if I could reproduce it myself, but can’t seem to, if that changes will post my findings as well. Just trying to rule out differences in response from the server, and other variables etc.
It’s just the standard ServiceStack Web template with a little global request filter added to return a 429 and set the response header for all requests.
Looks like this issue is due to WebRequest vs HttpClient. Using the following project with your same example captures the 429, but it looks like this might be a limit since the exception will fire before any ResponseFilters are processed when it comes to the WebRequest version on the .NET Framework as opposed to the HttpClient implementation on .NET Core.
A work around would be to access the information via the Exception if possible. Eg,
public static class Utils
{
/// <summary>
/// Reads Response content in string from WebException
/// Based on https://stackoverflow.com/a/74541238
/// </summary>
/// <param name="webException"></param>
/// <returns></returns>
public static (HttpStatusCode statusCode, string? responseString,WebHeaderCollection responseHeaders) GetResponseStringNoException(this WebException webException)
{
if (webException.Response is HttpWebResponse response)
{
Stream responseStream = response.GetResponseStream();
StreamReader streamReader = new StreamReader(responseStream, Encoding.Default);
string responseContent = streamReader.ReadToEnd();
HttpStatusCode statusCode = response.StatusCode;
streamReader.Close();
responseStream.Close();
response.Close();
return (statusCode, responseContent,response.Headers);
}
else
{
return (HttpStatusCode.InternalServerError, null,null);
}
}
}
And in the client, you can use:
catch (Exception ex)
{
if(ex is WebException webEx)
{
var result = webEx.GetResponseStringNoException();
if (result.statusCode == (HttpStatusCode)429)
{
Console.WriteLine(result.responseString);
retryAfterResponseHeader = result.responseHeaders.Get("Retry-After");
}
}
Console.WriteLine($"Exception encountered: {ex.Message}");
}
Definitely not ideal, but due to how HttpWebRequest works on the .NET Framework, not another option I can currently see.
Thanks - just a few minutes before you posted your answer, I had already moved away from using HttpUtils to using the .NET Framwework’s HttpClient and that’s all working fine for me.
Is there any reason why the .NET Framework flavour of ServiceStack HttpUtils uses WebRequest instead of HttpClient like the .NET Core version of ServiceStack HttpUtils does?
HttpUtils was originally developed to use HttpWebRequest initially and the .NET Framework continues to use the Windows HttpWebRequest for backwards compatibility. In .NET Core HttpWebRequest is a completely different implementation (than the Windows only version of HttpWebRequest in .NET Framework) that’s an unsupported wrapper around HttpClient which has since been deprecated which is why the .NET 6 version implementation was rewritten to use HttpClient in order for HttpUtils to use a supported HttpClient implementation.
