Adding HTTP method constants#712
Conversation
| public const string Put = "PUT"; | ||
| public const string Trace = "TRACE"; | ||
|
|
||
| public static bool Equals(string firstMethod, string secondMethod) |
There was a problem hiding this comment.
Do we need this? Where are we going to use it?
|
a more optimized approach would be to have methods for each of the verbs that does a reference equality before doing the case insensitive matching. Since we're declaring static strings we may as well use them.... |
|
Should these be consts or static readonly? |
|
Let's not do this in 1.1. We'll consider this later. |
|
|
||
| public static bool IsConnectMethod(string inputMethod) | ||
| { | ||
| return object.ReferenceEquals(Connect ,inputMethod) | StringComparer.OrdinalIgnoreCase.Equals(Connect, inputMethod); |
There was a problem hiding this comment.
Wrong or, we don't want bitwise or here. You need ||.
There was a problem hiding this comment.
nit: Connect , -> Connect,
There was a problem hiding this comment.
When you said "you need | " I figured you meant an extra one
|
@muratg why? |
|
@davidfowl unnecessary churn, no? |
| return object.ReferenceEquals(Connect ,inputMethod) | StringComparer.OrdinalIgnoreCase.Equals(Connect, inputMethod); | ||
| } | ||
|
|
||
| public static bool IsDeleteMethod(string inputMethod) |
|
Why do case-insensitive comparison when the RFC says method names are case-sensitive? https://tools.ietf.org/html/rfc7230#section-3.1.1 |
|
@CesarBS because in practice they are case-insensitive. |
| using System.Collections.Generic; | ||
| using Microsoft.AspNetCore.Http.Features; | ||
| using Xunit; | ||
| using Microsoft.AspNetCore.Http; |
| { | ||
| return object.ReferenceEquals(Trace, method) || StringComparer.OrdinalIgnoreCase.Equals(Trace, method); | ||
| } | ||
| } |
There was a problem hiding this comment.
we should still have the Equals(string, string) method
| return object.ReferenceEquals(Trace, method) || StringComparer.OrdinalIgnoreCase.Equals(Trace, method); | ||
| } | ||
|
|
||
| public static bool Equals(string left, string right) |
There was a problem hiding this comment.
This method is pointless... We hard code a few methods there's no point having a case insensitive overload here. It adds nothing..
There was a problem hiding this comment.
I'm gonna let you and @Tratcher settle this...
|
Where's |
|
Its there now 😄. Good catch |
| return object.ReferenceEquals(Get, method) || StringComparer.OrdinalIgnoreCase.Equals(Get, method); | ||
| } | ||
|
|
||
| public static bool IsHeadMethod(string method){ |
| return object.ReferenceEquals(Delete, method) || StringComparer.OrdinalIgnoreCase.Equals(Delete, method); | ||
| } | ||
|
|
||
| public static bool IsGetMethod(string method) |
There was a problem hiding this comment.
HttpMethod.IsGetMethod(string) seems redundant. What about just HttpMethod.IsGet(string)?
|
|
||
| namespace Microsoft.AspNetCore.Http | ||
| { | ||
| public static class HttpMethods |
There was a problem hiding this comment.
Should this be singular?
HttpMethod.Get
HttpMethod.IsGet(string)
HttpMethod.Equals(string, string)
There was a problem hiding this comment.
Agreed. This is similar to a non-flag enum.
| return object.ReferenceEquals(Trace, method) || StringComparer.OrdinalIgnoreCase.Equals(Trace, method); | ||
| } | ||
|
|
||
| public static bool Equals(string left, string right) |
There was a problem hiding this comment.
Is this really necessary? If anything this could be private and called by the Is* methods.
There was a problem hiding this comment.
There was a big discussion on this. We're taking it out
| public const string Patch = "PATCH"; | ||
| public const string Post = "POST"; | ||
| public const string Put = "PUT"; | ||
| public const string Trace = "TRACE"; |
There was a problem hiding this comment.
I'm for keeping these const. ReferenceEquals still works across assembly boundaries. Just don't mess up 😛 .
There was a problem hiding this comment.
Yeah, constants would be nicer (e.g they could be used for attribute values) 👍
|
⬆️ 📅 |
What's the point of doing that manually? It's already something |
Good to know! https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/StringComparer.cs#L300 http://referencesource.microsoft.com/#mscorlib/system/stringcomparer.cs,285 We'll still do the work to use the same objects everywhere 😄 |
TBH, I'm not sure to understand why (and how) having a static field would be better than a good old constant. I'm definitely not a perf' expert, but I'd expect the CLR to be smart enough to intern these constants to avoid instantiating new strings every time you use them in your code. |
Because of interning, there's little to no difference between Since the compiler will burn There's also a drawback to using |
Strings are deduped within single assembly boundaries. There's no guarantee that strings are "reference equal" across assembly boundaries. Using the same static readonly field guarantees that. |
@davidfowl Did you read @khellang's comment?
I've tested this, and this is true. |
I tested it as well and it does work. Still best practice is to avoid const leaking across assembly boundaries no matter how little difference it makes on current runtimes. Maybe it'll break when corert comes around 😉 |
For issue #693
@Tratcher @muratg