You're completely right that this got fixed in ASP.NET 4, but I still think it's a fun read to see how an unyielding tribute to backwards compatibility can have really odd implications.
Given that this article is 6 years old, and the upcoming vNext is being touted as practically a rewritten v1.0 product... will this constraint still hold for the new ASP.NET coming next year?
Microsoft fixed this awhile ago; the constraint definitely is dead in vNext. You do, however, still need to set a flag explicitly to disable the behavior described in this post. http://haacked.com/archive/2010/04/29/allowing-reserved-file... has instructions on how this worked in ASP.NET 4, and I believe the situation is similar in 5.
Also, just to get this out of the way since it comes up every time this is posted, my description of CP/M is slightly incorrect; it turns out to have had a much saner COM/LPT/etc. situation than DOS had. The rest of the article was however correct.
Because the article is six years old and the fact you can now circumvent the error is irrelevant to its point. Besides, the linked SO question does indeed have the new information, and has for five years.
So? Readers of that post obviously are interested in whether it was ever fixed, as this HN discussion proves, and they aren't going to randomly click on a SO link just in case it might cover that topic.
Actually, it's easily fixable with:
relaxedUrlToFileSystemMapping="true"
(google that). It was fixable many years ago, and I have no any idea why today it is on hacker news, lol
You're completely right that this got fixed in ASP.NET 4, but I still think it's a fun read to see how an unyielding tribute to backwards compatibility can have really odd implications.
For classic asp you can avoid this when accessing files via the command line by using a extended file path format:
notepad \\?\c:\inetpub\wwwroot\com1.asp
http://localhost/com1.asp
This also has the hilarious result that "normal" windows tools can't delete the file without using the extended path.
Given that this article is 6 years old, and the upcoming vNext is being touted as practically a rewritten v1.0 product... will this constraint still hold for the new ASP.NET coming next year?
Original author here!
Microsoft fixed this awhile ago; the constraint definitely is dead in vNext. You do, however, still need to set a flag explicitly to disable the behavior described in this post. http://haacked.com/archive/2010/04/29/allowing-reserved-file... has instructions on how this worked in ASP.NET 4, and I believe the situation is similar in 5.
Also, just to get this out of the way since it comes up every time this is posted, my description of CP/M is slightly incorrect; it turns out to have had a much saner COM/LPT/etc. situation than DOS had. The rest of the article was however correct.
Why not edit both of those points into your post? It must be easier than chiming in on the comments section every time it's posted.
Because the article is six years old and the fact you can now circumvent the error is irrelevant to its point. Besides, the linked SO question does indeed have the new information, and has for five years.
So? Readers of that post obviously are interested in whether it was ever fixed, as this HN discussion proves, and they aren't going to randomly click on a SO link just in case it might cover that topic.
C:\con\con anybody remebering this?
Can someone add 2009 to the tile?
There was a system BSOD in IE, where you made an iframe that included these reserved names, crashed the OS.
[2009]
Why submit a 6 year old tech article? What's the context and relevance?
HackerNews isn't a current affairs site, or at least not only one. Interesting articles, whatever the age, are totally valid.
I know, I've been here three years now. I just assumed there was additional context for this article.