Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

Rename request body min rate APIs (#1901) #1915

Merged
merged 6 commits into from
Jun 30, 2017
Merged

Rename request body min rate APIs (#1901) #1915

merged 6 commits into from
Jun 30, 2017

Conversation

cesarblum
Copy link
Contributor

@cesarblum cesarblum commented Jun 23, 2017

public MinimumDataRate RequestBodyMinimumDataRate { get; set; } = new MinimumDataRate(rate: 1, gracePeriod: TimeSpan.FromSeconds(5));
public MinimumDataRate MinRequestBodyDataRate { get; } = new MinimumDataRate { BytesPerSecond = 1, GracePeriod = TimeSpan.FromSeconds(5) };

public class MinimumDataRate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like having a public nested class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feature uses two fields but the options use a custom type? Why is this type needed for options?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tratcher MinRequestBodyDataRate.BytesPerSecond matches how the feature is used better than MinRequestBodyDataRateBytesPerSecond. It's just aesthetics though.

get => _gracePeriod;
set
{
if (value < TimeSpan.Zero)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should throw for TimeSpan.Zero too, since that's just asking for problems.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still a legal value. Means the rate will be enforced right away. It's not recommended, but there's no technical reason to disallow it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The technical reason to disallow it is because setting it to zero creates a race that could cause any connection to be killed no matter the actual upload rate

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we should require it to be larger than 1 second.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, more precisely, larger than Heartbeat.Interval, which right now is one second.

get => MinRequestBodyDataRate.GracePeriod;
set
{
if (value < TimeSpan.Zero)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to share the validation logic between this and the MinimumDataRate class?

double BytesPerSecond { get; set; }

/// <summary>
/// The amount of time to delay enforcement of the minimum data rate.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Starting from when? After the request arrives? The first read?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add ", starting at the time data is first read or written." Written as well since this same type will (likely) be used for the response rate.

public MinimumDataRate RequestBodyMinimumDataRate { get; set; } = new MinimumDataRate(rate: 1, gracePeriod: TimeSpan.FromSeconds(5));
public MinimumDataRate MinRequestBodyDataRate { get; } = new MinimumDataRate { BytesPerSecond = 1, GracePeriod = TimeSpan.FromSeconds(5) };

public class MinimumDataRate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feature uses two fields but the options use a custom type? Why is this type needed for options?

@cesarblum
Copy link
Contributor Author

  • Reverted 5c63a58 to stop the bikeshedding
  • Moved MinimumDataRate to the base Core namespace so people don't need a weird using when setting it in KestrelServerLimits
  • Allow 0 bytes/second
  • Require the grace period to be larger than Heartbeat.Interval

@cesarblum cesarblum force-pushed the cesarbs/1901 branch 3 times, most recently from 778a6a6 to 524fb68 Compare June 29, 2017 17:46
@cesarblum
Copy link
Contributor Author

📢

@@ -6,7 +6,7 @@ namespace Microsoft.AspNetCore.Server.Kestrel.Core.Features
/// <summary>
/// Represents a minimum data rate for the request body of an HTTP request.
/// </summary>
public interface IHttpRequestBodyMinimumDataRateFeature
public interface IHttpMinRequestBodyDataRateFeature
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we should be abbreviating Minimum to Min

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about this for a little bit, I think we should change all usages of "Minimum" in public APIs to "Min" for consistency considering how many limits already use "Max".

So that means the MinimumDataRate class changes to MinDataRate, IHttpMinRequestBodyDataRateFeature.MinimumDataRate changes to IHttpMinRequestBodyDataRateFeature.MinDataRate, etc...

I don't care as much about private/internal names, but I think some of that could also change to match.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already change the property/param to bytesPerSecond, so that's taken care of. I'll change the type name now.

I went with Min because we already have Max on other properties.

Copy link
Contributor

@natemcmaster natemcmaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for MinDataRate over MinimumDataRate. It's more consistent. All other changes look fine to me.

@halter73
Copy link
Member

I meant to leave a comment with my approval. I approve this pending changing "Minimum" to "Min" in all public APIs.

@cesarblum
Copy link
Contributor Author

Updated, will merge when CI is green.

Cesar Blum Silveira added 6 commits June 29, 2017 16:34
…#1901).

- IHttpRequestBodyMinimumDataRateFeature -> IHttpMinRequestBodyDataRateFeature
- KestrelServerLimits.RequestBodyMinimumDataRate -> MinRequestBodyDataRate
- Also rename "rate" param and property of MinimumDataRate to "bytesPerSecond"
/// </summary>
/// <remarks>
/// Defaults to 1 byte/second with a 5 second grace period.
/// </remarks>
public MinimumDataRate RequestBodyMinimumDataRate { get; set; } = new MinimumDataRate(rate: 1, gracePeriod: TimeSpan.FromSeconds(5));
public MinDataRate MinRequestBodyDataRate { get; set; } = new MinDataRate(bytesPerSecond: 1, gracePeriod: TimeSpan.FromSeconds(5));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change this to match the IIS default. I believe it's 240 bytes/second.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separate change. Let's discuss it in the office tomorrow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here I was trying to avoid creating a new issue 😢

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@halter73
Copy link
Member

I know I already approved this. Hopeful changing the default is the last thing.

@cesarblum cesarblum merged commit f2061ed into dev Jun 30, 2017
@cesarblum cesarblum deleted the cesarbs/1901 branch June 30, 2017 00:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants