You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure whether this is a spec issue or a node implementation issue but the results is the same in node and the browser. Basically the new standard converts the non-ip 10.1000 into the valid IP 10.0.3.232
In the old standard it is left as is.
As part of our tests we have this bad input we want to reject:
https://10.1000/f<script>alert(1);</script>
(This is supposed to represent a valid yet potentially harmful DOI prepended by the wrong protocol)
Should it actually be doing this? Obviously dois shouldn't be prepended with the wrong protocol, but wondering if instead the behaviour should be to throw an error instead of accepting it but converting it to something unrecognisable?
I know consecutive 0s are allowed to be omitted, but 10.0.0.1000 isn't valid either because there are 4 digits in the last place (the minimum length for the second number in doi prefixes precisely to prevent confusion with ip addresses)... anyone know what's happening with the parser :)?
The text was updated successfully, but these errors were encountered:
For compatibility, the IP address parser supports the same formats as inet_aton. This includes the following format:
a.b
Part a specifies the first byte of the binary address. Part b is interpreted as a 24-bit value that defines the rightmost three bytes of the binary address. This notation is suitable for specifying (outmoded) Class C network addresses.
Since the second number is a 24-bit integer, 1000 is a valid value for it to have.
I'm not sure whether this is a spec issue or a node implementation issue but the results is the same in node and the browser. Basically the new standard converts the non-ip 10.1000 into the valid IP 10.0.3.232
In the old standard it is left as is.
As part of our tests we have this bad input we want to reject:
https://10.1000/f<script>alert(1);</script>
(This is supposed to represent a valid yet potentially harmful DOI prepended by the wrong protocol)
In browser:
https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly8xMC4xMDAwL2Y8c2NyaXB0PmFsZXJ0KDEpOzwvc2NyaXB0Pg==&base=YWJvdXQ6Ymxhbms=
In Node:
Both url.parse and new URL are fine with this as an origin, which is fine, we deal with that downstream. What's odd is how it's parsed:
With the updated api it "invents" an IP address for it, so the output is
The old url.parse output keeps the pseudo IP address as it is ->
Should it actually be doing this? Obviously dois shouldn't be prepended with the wrong protocol, but wondering if instead the behaviour should be to throw an error instead of accepting it but converting it to something unrecognisable?
I know consecutive 0s are allowed to be omitted, but 10.0.0.1000 isn't valid either because there are 4 digits in the last place (the minimum length for the second number in doi prefixes precisely to prevent confusion with ip addresses)... anyone know what's happening with the parser :)?
The text was updated successfully, but these errors were encountered: