- From: Michael[tm] Smith <notifications@github.com>
- Date: Thu, 02 Aug 2018 03:11:26 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/408/409877416@github.com>
> From the spec it seems that because `c` is `@` we would receive a validation error? Yes, it triggers a validation error. But that doesn’t mean parsing fails, and that step in the algorithm doesn’t fail. So your implementation moves on to parse the username and password and set them. See https://url.spec.whatwg.org/#validation-error: > A **validation error** indicates a mismatch between input and valid input. User agents, especially conformance checkers, are encouraged to report them somewhere. > **Note:** A validation error does not mean that the parser terminates. Termination of a parser is always stated explicitly, e.g., through a return statement. > It is useful to signal validation errors as error-handling can be non-intuitive, legacy user agents might not implement correct error-handling, and the intent of what is written might be unclear to other developers. So if your implementation eports validation errors, then you just report the validation error and keep parsing. There’s no failure. Or if instead implementation doesn’t report validation errors, then the validation error is just a noop — and again in that case, you just keep parsing. > I also don't see how the username and password can be set without hitting a validation error? The username and password can’t be set without hitting a validation error. But setting the username and password is orthogonal to reporting the validation error. The validation error doesn’t cause failure. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/408#issuecomment-409877416
Received on Thursday, 2 August 2018 10:12:15 UTC