1

I have just upgraded my ASP.NET application from .NET 3.5 to 4.0 and have found that the Request.RawURL is set to "/" when requesting the default document, default.aspx, via http://mysite.com/. In .NET 3.5, the Request.RawURL would be set to "/default.aspx".

Is there any way to enable this .NET 3.5 behavior in 4.0?

I have tried disabling extensionless URLs via the registry. I also went through the ASP.NET 4.0 Breaking Changes doc and have set the form tag action attribute, however viewing the source of the page shows that the value set for the action attribute is not being picked up and is reverting back to "/".

Currently running on IIS 7.5 integrated mode and Win7.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Andrew
  • 419
  • 4
  • 8

1 Answers1

1

Indeed, I can reproduce the behavior when switching between .NET 2.0 and .NET 4.0 -- .NET 2.0 & 3.5 both share the same Common Language Runtime CLR2, with additions to the base class library (BCL) for the higher versions of .NET. With .NET 4.0 came CLR4 and that seems to be where the difference occurs. I never noticed that before!

I believe the new behavior is correct, as RawUrl reflects the URL path that was actually requested. It's difficult to understand your exact need, but I think you might try using Request.Path instead.

URL: http://example.com/
Request.RawUrl: /
Request.Path: /default.aspx

Perhaps you can elaborate a bit more on your application?

Kevin P. Rice
  • 5,550
  • 4
  • 33
  • 39
  • RawUrl was used in a few places in the app, so they needed just a small change to get working. I was hoping that the issues would be related and there would be a fix to get the RawUrl and also the action attribute set properly. The main issue with the action attribute not being set is that event handlers aren't being raised . I can get around this issue as mentioned in [this question](http://stackoverflow.com/questions/8995557/how-to-set-form-action-attribute) but I feel like this isn't the best solution. – Andrew Jan 28 '12 at 07:08
  • I think the answer to your problem lies right here in the Breaking Changes document: http://www.asp.net/whitepapers/aspnet4/breaking-changes#0.1__Toc256770154 – Kevin P. Rice Jan 28 '12 at 17:19
  • I've read that as mentioned in my post. The recommended changes don't solve the issue. – Andrew Jan 30 '12 at 11:55