5

Right now questions tagged soapi.cs returns a HTTP status code 404 (for various HTTP clients) while questions tagged soapi.js does not.

Interestingly though, soapi.cs seems to work just fine in other places, e.g. Newest soapi.cs questions returns the desired result, and so does Stats on soapi.cs. That is, as soon as (sort) parameters are included the route seems to work as expected, but not without?

What's the magic difference here?

Improve this question
2

1 Answer 1

Reset to default
3

IIS ASP.net, by default, prohibits service of many file extensions, .cs is one.

So the request is being killed by IIS ASP.net before it hits the REST handlers.

This can be fixed fairly easily by striking the following entry, if so desired...

%SYSTEM%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.Config

....
<httpHandlers>
   <add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="True"/>
....

But subverting ASP doesn't seem to be a solution to me.

Perhaps naked links like that can be rendered with a filter that contains the forbidden extensions and just munge them a bit as systempuntoout has demonstrated.

Or perhaps add a filter to tag creation to prevent such tags from being created. But I think i like the munge better.

But the bottom line is that something should be done, otherwise arbitrary numbers of tag links are just going to be bad. It is not so apparent here, but on SO...

hey, i wonder...

Sure enough https://stackoverflow.com/questions/tagged/.cs

Nice catch Steffen.

And of course this is just my supposition. I am not privy to the inner workings of the SO servers.

But I do have a bit of experience with how an HttpWorkerRequest behaves.

If anyone needs a better dev server than the one that comes with VS08 or VS10 you can get one here

Improve this answer
9
  • I see, makes sense - but why do the parameters or appending an underscore (as per @systempuntoouts comment on the question) make a difference? And this still qualifies as a (likely easy to fix) bug in the IIS configuration at hand, after all, the respective route is not in the file system, right?
    – Steffen Opel
    Commented Aug 13, 2010 at 10:58
  • @steffen - because you are no longer requesting a c# source file. xxx/soapi.cs looks to IIS as a request for a file of that name. xx/soapi.cs_ does not match the pattern
    – Sky Sanders
    Commented Aug 13, 2010 at 11:00
  • @code yep, but it returns soapi.cs tagged questions.
    – systempuntoout
    Commented Aug 13, 2010 at 11:05
  • @code - as obvious I'm not fluent at all in IIS operation and configuration, I'm mostly dealing with Apache and/or JVM application servers for my web service needs; and over there the definition of a route doesn't (necessarily) depend on whether parameters are present or not, rather the respective parameter processing is usually done after the fact per route selected by the request URI without query string. Of course, the behaviour you describe can be configured with Apache as well, I'm just surprised this applies in the context of a REST application servicing the respective URL space already.
    – Steffen Opel
    Commented Aug 13, 2010 at 11:05
  • @steffen, the salient issue is that xxx/xxx.cs does not contain parameters. It is seen as a request for a physical path before the REST handler get it. See answer for detail.
    – Sky Sanders
    Commented Aug 13, 2010 at 11:17
  • @system - it is likely that the underscore is being treated as noise and being stripped before processing.
    – Sky Sanders
    Commented Aug 13, 2010 at 11:21
  • @code - got you already, so (assuming it will be fixed soon) we can put this issue at rest ;) I just tried to explain why it surprises me, that the default IIS configuration is apparently evaluating the physical path before any handler configured for that route is even involved. IIRC this is just the other way round elsewhere, i.e. once I configure a handler for a route I'd need to wire in an exception via URL rewriting explicitly for example to evaluate the physical path before that handler - and defaulting like this makes more sense to me as well, but may just be something I'm used to.
    – Steffen Opel
    Commented Aug 13, 2010 at 11:25
  • @steffen - I actually misspoke, it is ASP.NET that is choking on the request, not IIS. The extension mapping is in the root web.config and unless it is overridden in a subsequent .config, which there is no reason to believe it is or that it should have been, the worker process is going to dump it before subsequent handlers or modules get a chance to process it.
    – Sky Sanders
    Commented Aug 13, 2010 at 11:34
  • Ah, right, forgot that you are in the ASP.NET server business also, pretty impressive - will try to recall this once I'm going to dive deeper into the web service side of .NET as well!
    – Steffen Opel
    Commented Aug 13, 2010 at 11:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .