Inconsistent handling of negative values in HeaderUtilities.TryParseInt64/FormatInt64

[halter73]

HeaderUtilities.FormatInt64 will create a string for a negative number even though HeaderUtilities.TryParseInt64 will throw trying to parse it.

[JunTaoLuo]

Yea, we can make it consistent and get TryParseInt64 to parse negative values. Is there any use case for it currently?

[Tratcher]

Other way around, we don't want negatives in either API

[JunTaoLuo]

Maybe we should change it to TryParseUInt64 and FormatIntUInt64 and parse to/format ulong instead long? Might be a dramatic change though with updates in several other repos.

[muratg]

We don't use unsigned integer types in the public API.

One idea HeaderUtilities.TryParseInt64 to HeaderUtilities.TryParseNonNegative (yuck!) or something. Backlogging for now.

[halter73]

@muratg Can we reconsider? This is a new API, and I don't think we need to rename anything. Just make HeaderUtilities.FormatInt64 throw for negative values like HeaderUtilities.TryParseInt64. Is there a real use case for putting negative longs from response headers? More real than parsing negative values from request headers?

[JunTaoLuo]

This is not a new API, it existed in previous versions. It was just using long.Parse() instead. We don't need to parse/format negative numbers so throwing is fine. However, since we will throw for negative numbers, we were considering renaming it to be more consistent with what it does hence {Format/Parse}NonNegativeInt64 but that naming looks bad. We could just mention it in the doc comments though.