Address limits on unconstrained inputs #520
Conversation
The second half of this paragraph is from the HTML Standard.
|
@jyasskin care to review as well? |
Infra handles that as per whatwg/infra#520.
|
Oh, and even if we discourage exact limits, I think we should allow minimum sizes on the implementation-defined limits, like https://httpwg.org/specs/rfc9110.html#uri.references recommends for URIs. |
|
@smaug---- @martinthomson care to comment on behalf of Firefox as suggested above? |
Co-authored-by: Domenic Denicola <d@domenic.me>
|
Anyone want to do another pass? I'll merge this Monday if there's no further feedback. |
|
|
||
| <p tracking-vector>Nevertheless, user agents may impose <a>implementation-defined</a> limits on | ||
| otherwise unconstrained inputs. E.g., to prevent denial of service attacks, to guard against running | ||
| out of memory, or to work around platform-specific limitations. |
There was a problem hiding this comment.
Inspired by #520 (comment):
| out of memory, or to work around platform-specific limitations. | |
| out of memory, or to work around platform-specific limitations. Specifications should define what | |
| happens when input exceeds such an <a>implementation-defined</a> limit. |
I'm not sure that's exactly the right wording or location.
There was a problem hiding this comment.
I don't think we can require this. At the very least it should be a follow-up discussion. E.g., consider out-of-memory. Currently implementations can impose limits and throw an exception or they can let the entire process crash. We wouldn't want specifications to constrain that.
There was a problem hiding this comment.
It's already "should" rather than "must", but maybe with "if doing so is reasonable"? I agree that we won't be able to do it in all cases, but I wanted to encourage people to try. Even in the case of memory limits, something should specify the type of error thrown if one is thrown.
I have no problem making that a follow up discussion.
infra.bs
Outdated
| <p>There are at least two cases where a limit can be useful to define: | ||
|
|
||
| <ul class=brief> | ||
| <li>Ensuring all implementations can handle inputs of a given minimum size, i.e., a lower limit. |
There was a problem hiding this comment.
This is a bit awkward. Maybe:
| <li>Ensuring all implementations can handle inputs of a given minimum size, i.e., a lower limit. | |
| <li>Constraining an <a>implementation-defined</a> limit to be at least a particular minimum size. |
Even this wording isn't really a case "where a limit can be useful to define", so maybe it should move out of this list.
There was a problem hiding this comment.
Why not? Isn't a lower limit a limit?
There was a problem hiding this comment.
It's a limit on the limits implementations impose (a meta-limit?), while the rest of this section is about specifying limits on user code. So it's a bit of equivocation to use the same word, but I also don't object strongly. Do what you like after having heard the argument. 🙂
Infra handles that as per whatwg/infra#520.
Infra handles that as per whatwg/infra#520.
The second half of this paragraph is from the HTML Standard.
Preview | Diff