Timeline for What's the difference between tags soapi.cs and soapi.js to get a bug triggered by the former?
Current License: CC BY-SA 2.5
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:39 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Aug 13, 2010 at 12:21 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 679 characters in body
|
| Aug 13, 2010 at 12:15 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 25 characters in body
|
| Aug 13, 2010 at 11:38 | comment | added | Steffen Opel | 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! | |
| Aug 13, 2010 at 11:34 | comment | added | Sky Sanders | @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. | |
| Aug 13, 2010 at 11:31 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 314 characters in body
|
| Aug 13, 2010 at 11:25 | comment | added | Steffen Opel | @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. | |
| Aug 13, 2010 at 11:21 | comment | added | Sky Sanders | @system - it is likely that the underscore is being treated as noise and being stripped before processing. | |
| Aug 13, 2010 at 11:18 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 223 characters in body; added 98 characters in body
|
| Aug 13, 2010 at 11:17 | comment | added | Sky Sanders |
@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.
|
|
| Aug 13, 2010 at 11:05 | comment | added | Steffen Opel | @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. | |
| Aug 13, 2010 at 11:05 | comment | added | systempuntoout | @code yep, but it returns soapi.cs tagged questions. | |
| Aug 13, 2010 at 11:00 | comment | added | Sky Sanders |
@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
|
|
| Aug 13, 2010 at 10:58 | comment | added | Steffen Opel | 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? | |
| Aug 13, 2010 at 10:54 | history | answered | Sky Sanders | CC BY-SA 2.5 |