Fix to handle app name specifications with slashes. This is the CLI ... #471
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
change to match the corresponding server change deployed
a couple days back.
Here are details of the issue:
// IIS and Azure web apps have this annoying behavior where %2F (URL encoded slashes) in the URL are URL decoded
// BEFORE the requests reach node. That essentially means there's no good way to encode a "/" in the app name--
// URL encodeing will work when running locally but when running on Azure it gets decoded before express sees it,
// so app names with slashes don't get routed properly. See tjanczuk/iisnode#343 (or other sites
// that complain about the same) for some more info. I explored some IIS config based workarounds, but the previous
// link seems to say they won't work, so I eventually gave up on that.
// Anyway, to workaround this issue, we now allow the client to encode / characters as ~~ (two tildes, URL encoded).
// The CLI now converts / to ~~ if / appears in an app name, before passing that as part of the URL. This code below
// does the encoding. It's hack, but seems like the least bad option here.
// Eventually, this service will go away & we'll all be on Max's new service. That's hosted in docker, no more IIS,
// so this issue should go away then.