I have a hosted servicestack web app on which I’m submitting a GET request to a DeckSearches service.
For some reason a certain combination of properties on the request object causes a 404 and I’m trying to get the hosting company to understand that it isn’t ServiceStack (as the same thing doesn’t happen on any of my local environments with the same codebase, db etc).
I can perform a search with (Format = Standard and Min Dice = 6) and get a number of results successfully.
I can then decrease the Min Dice value down through 5 and 4 and continue to get results.
But, I get a 404 if I then lower it again to 3. The query string doesn’t change other than changing the minDice value from 4 to 3 yet it throws a NotFound exception. I’m certain this is something to do with the hosted IIS environment but would appreciate some ideas on how this can be the case, if anyone has any…?
The main impact I would expect lowering the minDice value would have is to increase the size of the response object (quite substantially), could that be anything to do with it?
My issue with this is that it appears to throw the exception within a couple of seconds but I would expect the corresponding db search to take about 10 seconds before anything was aware of the response object’s size…
This description isn’t useful on its own, you really need to be looking at the underlying HTTP Request/Response headers and comparing them to see what the actual differences are. Whether both requests are being handled by ServiceStack or if it fails before it reaches ServiceStack, whether there’s something different about how the requests are created, what other info is available in the 404 responses, etc.
Please include the Request Headers for both as well.
Does your Service throw a NotFound Exception for any reason? What does your implementation do? Does it make a 3rd Party API call? And does that return a 404 for any reason?
It says you’re going through WebWiz.net, is that some kind of proxy and does that provide its own caching? If it does then it could be returning a cached version, try seeing if you can break the cache with an additional param with a unique number, e.g:
Remove that Exception and let it the original Exception bubble and make sure you have a ResponseStatus in your Response DTO to see details about what the Exception is:
public class DeckSearchResponse
{
public ResponseStatus ResponseStatus { get; set; }
}
You’ll need to enable DebugMode in order to view the StackTrace in the response.