-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is Period the best parts separator for Queue/Topic/Subscription Paths? #43
Comments
I'm a bit confused by this, I get what you're saying about IIS.. but are you trying to address a queue in a way that you're getting a 404 ? |
Yeah, it's not really related to running Nimbus as a Service Bus, but I I was using the queue path as part of the URL in a web request to get dead For example: DELETE /deadletters/q.myqueue IIS responded to this request with a 404 treating "q.myqueue" as a file Appending a '/' to the end of the URL fixed the immediate problem: Just thought to ask the question in case there was a more universally Either way this is probably a corner case and could happily be ignored. On Thu, Feb 13, 2014 at 4:25 PM, Damian Maclennan
|
This is a known pain in the backside when dealing with MVC routing on IIS - it treats anything with a . that doesn't precede a slash as a static filename rather than a parameter. Not sure how much we want to care about it in this context, though - is it likely to come up often? Thoughts? |
The default parts separator for creating the Path to service bus entities in Nimbus is '.' (a period) which is fine in most situations though it can be problemmatic in URLs.
A specific example is that by default IIS will treat a request ending with something that looks like a file as a request for a static resource and returns 404 when it can't find the file on the file system. You can work around this by adding a trailing '/' to the URL or by specifically adding an exception in web.config.
I'm just wondering if period is the most appropriate parts separator?
Perhaps Nimbus could offer some customisable conventions?
The text was updated successfully, but these errors were encountered: