I have implemented a GlobalRequestFilter that returns a '304 - NotModified'.
public static Action<IRequest, IResponse, object> HandleHttpExpirationByETagFilter()
return (request, response, dto) =>
if (request.Verb != HttpMethods.Get)
var matchETag = request.Headers[HttpHeaders.IfNoneMatch];
if (matchETag == null)
// set some other response headers...
response.StatusCode = (int)HttpStatusCode.NotModified;
I am using a JsonServiceClient to call the service, and the JsonServiceClient.Get() is throwing a "WebServiceException: Not Modified".
I was not expecting an exception. Is this normal behavior for a service?
Yep it consistently throws on
JsonHttpClient and raw WebRequest as seen in this commit.
OK, great thanks for the confirmation.
And if I wanted to change my JsonServiceClient to not throw, and just return an empty response, how can I do that easily, or I am overriding HandleResponseException() to do that?
BTW: It would be nice to understand the rationale behind why 304 is implemented as an exception in SS.
It's not built in ServiceStack, the tests are showing that 304's all throw consistently in both .NET's built-in
HttpWebRequest as well as Microsoft's newer
HttpClient, I don't know of a way to suppress the Exceptions for 304 responses.
Yeah that looks like the only way to handle the exception and return a response.
My interpretation of various references on the correct behaviour of HTTP services that respond with 304 to with HTTP Validation using If-None-Match: ETag, is that the client may need to read other headers like ETag, Expires and Cache-Control that are also sent by the server along with the 304 in the response.
But if the client throws an exception, that data will almost certainly be lost.
Appreciate MS is throwing exceptions in their implementations. That's a shame, not much SS can do about that then I guess. Bugger! They don't always get everything right those MS guys, (lowering my head in shame).