http://mysite/?foo=bar[date] [servername] GET / foo=bar&foo=bar&X-ARR-LOG-ID=[guid]I have duplicated this in two different node apps. One app uses a custom iisnode.yml and web.config but they are not too far off from the defaults. The other app does not use a custom iisnode.yml or web.config but instead has them generated by the kudu deployment command. The first app uses node 7.7.4 and the second uses 8.0.0.
I believe the URL logged in the web server logs comes straight from IIS and is not affected at all by the node app itself. Therefore I think the issue is either in the IIS configuration further up the chain or some other process that I'm unaware of.
I also happen to have a .NET application deployed to App Services as well that does not exhibit the issue.
I discovered this because of an issue with the querystring being too long and hitting requestFiltering limits. Despite the original querystring being under the limit, the duplicated value put it over and triggered IIS filtering those requests into 404.15.
@jbrantly this sounds like something happening at runtime, and not related to Kudu (which only takes care of the deployment).
Is the duplication only in the log, or do you actually see it at runtime in your Node app?
I tried printing req.url from a trivial Node app, and duplication doesn't happen (though I do see it in the http log).
So I found what's causing it, but I don't really understand it. The default web.config we generate has this to allow serving static content from public folder:
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
And somehow it has the side effect of duplicating the query string in the http log. @rramachand21 does that make any sense to you, given that the path does not match this pattern at all?
Is the duplication only in the log, or do you actually see it at runtime in your Node app?
I don't see it at runtime in the Node app which is good. However, its more than just showing in the log as it apparently affects IIS request filtering.
Ok, I figured it out. Instead of public{REQUEST_URI}, it should be public{PATH_INFO}.
Can you give this a try? Go in Kudu console, and modify web.config in your site\wwwroot folder, then try again.
I can confirm that fixes the log file and the request filtering issue. Thanks!
I can't comment on whether or not that breaks the static content stuff 馃槃
I did a basic test and static content still works. However, we've been using this same config for like 5 years, so I'm too scared to make this change given that the issue is harmless and the potential to break things is there. If someone runs into this and is annoyed by it, hopefully they can find this issue and hand fix it.
If we get a ton of feedback, maybe we can reconsider, but for now, let's leave this alone :)
This is still a bug! And the reason is that the StaticContent rule uses REQUEST_URI, which include the query string, but also has AppendQueryString set to true (the default), so after the rewrite rule the URL gets split again between path and query, and now the query is doubled.
This bug effectively halves the maximum URL length, from the usual 2048 bytes to 1024!
@davidebbo There's no reason an app would want all query parameters to be double! If you don't want to change the rule to use PATH_INFO, at least consider setting AppendQueryString to false.
Failed Request Trace Log:
For the record, this is the faulty line in the template:
Changing it to PATH_INFO. Based on some more testing, it doesn't seem to break anything. Though it still comes with a risk since it's been like that for years. We'll see.
Note that this change is now fully deployed. Please verify that it all works with no workarounds now.
Works!
Most helpful comment
Changing it to
PATH_INFO. Based on some more testing, it doesn't seem to break anything. Though it still comes with a risk since it's been like that for years. We'll see.