Add raw request URI property to IHttpRequestFeature

[cesarblum]

Path and PathBase might lose some information. Expose the raw, unaltered request URI via the new property.

Related: aspnet/KestrelHttpServer#594

This will also mitigate the loss of information in aspnet/KestrelHttpServer#709 and aspnet/KestrelHttpServer#666.

[Eilon]

@blowdart because we always freak out with regard to security and so-called "raw" URLs. I'm personally a fan of giving raw access to data, but URLs can be dangerous unless you really, really, really know what you're doing.

[Tratcher]

Yes, sufficiently so that I'd considered making it its own feature, but that seem a little excessive.

[Eilon]

I should add a corollary to my earlier comment:

It is a well-known fact that when it comes to URLs, no one knows what they're doing.

[blowdart]

I have no real objection to them being exposed. However we mustn't use them anywhere ourselves. We must always operate on the canonicialized string.

The doc comments should reflect the danger of using URLs in their RAW forms.

[Tratcher]

Can we add an attribute that makes using that field a compiler warning you need to suppress? Obsolete(Warning)?

[halter73]

I think marking the Raw URL getter as deprecated/obsolete would be very misleading considering we have no plans to expose the same data in a newer/better API.

[Tratcher]

I know Obsolete isn't ideal, but it's the only one I'm aware of that triggers a compiler warning. Are there others?

[Eilon]

Please don't mark it as obsolete. There is no other attribute that does this. Either we add the property and it's a real property, or we don't add it at all.

[muratg]

@CesarBS Let's do this in 1.0