Earlier this year
-
r121
(Use size_t for string lengths to avoid compiler warnings.
P...) committed by brettw
- Use size_t for string lengths to avoid compiler warnings.
Patch by Gregory Dardyk
Use size_t for string lengths to avoid compiler warnings.
Patch by Gregory Dardyk
-
r120
(Fix encoding of the query part of an URL.
Encoding of the q...) committed by brettw
- Fix encoding of the query part of an URL.
Encoding of the query part of an URL was inconsistent:
If it was part of a larger relative URL, it would get encoded.
However, if the query part was stand-alone, then it would not be encoded.
As indicated by the original layout test referenced in the bug (see below),
this patch changes the code so that the query part is encoded in both cases.
Note, however, that with this patch the layout test will NOT yet fully pass,
since it also handles the fragment part differently.
As the different handling of the fragment part seems to be quite on purpose,
I have not modified the behavior - see the discussion at
http://code.google.com/p/chromium/issues/detail?id=20507 .
BUG=20507, 8912
TEST=LayoutTests/http/tests/uri/resolve-encoding-relative.html
Patch by Roland Steiner, review URL http://codereview.chromium.org/243028
Fix encoding of the query part of an URL.
Encoding of the query part of an URL was inconsistent:
If it was part of a larger relative URL, it would get encoded.
However, if the query part was stand-alone, then it would not be encoded.
As indicated by the original layout test referenced in the bug (see below),
this patch changes the code so that the query part is encoded in both cases.
Note, however, that with this patch the layout test will NOT yet fully pass,
since it also handles the fragment part differently.
As the different handling of the fragment part seems to be quite on purpose,
I have not modified the behavior - see the discussion at
http://code.google.com/p/chromium/issues/detail?id=20507 .
BUG=20507, 8912
TEST=LayoutTests/http/tests/uri/resolve-encoding-relative.html
Patch by Roland Steiner, review URL http://codereview.chromium.org/243028
-
-
issue 13
(uint64 not defined in basictypes.h for url_canon_ip.cc) reported by VeXocide
-
-
r119
(Remove ICU dependency from url_canon_internal. We were just ...) committed by brettw
- Remove ICU dependency from url_canon_internal. We were just picking up some
types and MAX* values for those tyeps from ICU, and weren't using it for
anything else in this context.
Patch by Matthew Steele
Remove ICU dependency from url_canon_internal. We were just picking up some
types and MAX* values for those tyeps from ICU, and weren't using it for
anything else in this context.
Patch by Matthew Steele
-
-
-
-
-
r115
(Update the unit tests to allow a colon in UNC hostnames on W...) committed by brettw
- Update the unit tests to allow a colon in UNC hostnames on Windows. This test
was broken in r107 but we weren't running the tests properly so never noticed.
Colon is probably not allowed by Windows, but its the "natural" result of the
way the canonicalizer is written. There doesn't seem to be a strong argument
for why allowing it here would be bad, so we just tolerate it and the load will
fail later.
Review URL: http://codereview.chromium.org/173535
Update the unit tests to allow a colon in UNC hostnames on Windows. This test
was broken in r107 but we weren't running the tests properly so never noticed.
Colon is probably not allowed by Windows, but its the "natural" result of the
way the canonicalizer is written. There doesn't seem to be a strong argument
for why allowing it here would be bad, so we just tolerate it and the load will
fail later.
Review URL: http://codereview.chromium.org/173535
-
r114
(Use U_ICU_VERSION_SHORT macro instead of hard-coding icu dat...) committed by brettw
- Use U_ICU_VERSION_SHORT macro instead of hard-coding icu data dll and module
name.
BUG=8198
TEST=googleurl test should be built and run without a problem.
Patch by Jungshik Shin
Review: http://codereview.chromium.org/174265
Use U_ICU_VERSION_SHORT macro instead of hard-coding icu data dll and module
name.
BUG=8198
TEST=googleurl test should be built and run without a problem.
Patch by Jungshik Shin
Review: http://codereview.chromium.org/174265
-
r113
(All host names with nonascii characters (cyrillic) + escapab...) committed by brettw
- All host names with nonascii characters (cyrillic) + escapable characters
(,)... were shown corrupted in suggestion box in Omnibox2, because we escaped
punicode string after it was created. I added some more escaping before IDNA
conversion.
Unittest updated, and main method added so we can init ICU data properly.
http://crbug.com/5490
TEST=Follow bug description, and make sure that test is as expected (orignal
text+%28).
Patch by: cira@chromium.org
Review: http://codereview.chromium.org/160589
All host names with nonascii characters (cyrillic) + escapable characters
(,)... were shown corrupted in suggestion box in Omnibox2, because we escaped
punicode string after it was created. I added some more escaping before IDNA
conversion.
Unittest updated, and main method added so we can init ICU data properly.
http://crbug.com/5490
TEST=Follow bug description, and make sure that test is as expected (orignal
text+%28).
Patch by: cira@chromium.org
Review: http://codereview.chromium.org/160589
-
-
-
-
issue 10
(% in the username gets escaped when canonicalizing GURL) changed by willchan@chromium.org
-
Status:
Fixed
Owner:
willc...@chromium.org
Status:
Fixed
Owner:
willc...@chromium.org
-
-
issue 9
(http://user:pass@/ should be an invalid url) changed by willchan@chromium.org
-
Status:
Fixed
Owner:
willc...@chromium.org
Status:
Fixed
Owner:
willc...@chromium.org
-
-
r110
(Expose in url_canon_ip.h the previously internal-only functi...) committed by eroman@chromium.org
- Expose in url_canon_ip.h the previously internal-only functions:
url_canon::IPv4AddressToNumber()
url_canon::IPv6AddressToNumber()
Motivation:
I would like to use url_canon::IPv6AddressToNumber() in some chromium
network tests, to create mock IPv6 socketaddrs.
The system-provided equivalents (like getaddrinfo() or inet_ntop()) are
unreliable for this purpose, since they only work on IPv6-enabled
machines.
BUG=NONE
TEST=NONE
R=brettw
Expose in url_canon_ip.h the previously internal-only functions:
url_canon::IPv4AddressToNumber()
url_canon::IPv6AddressToNumber()
Motivation:
I would like to use url_canon::IPv6AddressToNumber() in some chromium
network tests, to create mock IPv6 socketaddrs.
The system-provided equivalents (like getaddrinfo() or inet_ntop()) are
unreliable for this purpose, since they only work on IPv6-enabled
machines.
BUG=NONE
TEST=NONE
R=brettw
-
-
-
r108
(Make DoCanonicalizeIPv6Address safer by changing loop condit...) committed by brettw
- Make DoCanonicalizeIPv6Address safer by changing loop condition and
adding a DCHECK
Patch by yuzo@chromium.org
Original review URL: http://codereview.chromium.org/155077
-
r107
(url_canon: New CanonicalizeHostVerbose() function.
This fun...) committed by pmarks@google.com
- url_canon: New CanonicalizeHostVerbose() function.
This function allows the caller to distinguish between 4 cases:
- A valid, canonical IPv4 address.
- A valid, canonical IPv6 address.
- A "broken" address. This is something which kinda almost looks like an IP
address, but has been deemed to be invalid. For IPv4, this indicates a
numerical component which is longer than 16 digits, or one which can't be
used without truncation/overflow. For IPv6, this is any non-parseable
address containing a colon or square brackets.
- "neutral". This indicates that the output doesn't really look like an
IP address at all, and should probably be treated as a hostname.
The CanonHostInfo struct is meant to be extensible. In addition to the 4 cases
above, it also returns the number of components used to make an IPv4 address,
which will be useful to Chromium, and will make it possible stop exposing
FindIPv4Components.
This is the first step toward making Chrome behave better for these cases:
- http://[www.google.com]/
- http://192.168.0.0000000000000000000000000001/
- http://192.168.0.99999/
Edit:
- Changed the signature of CanonicalizeIPAddress(), instead of creating
a new "Verbose" version.
- For completeness, now includes the CanonicalizeHost() changes,
with an extended-output CanonicalizeHostVerbose(), because some callers
only care whether the canonicalization was a success or not.
Code review:
http://codereview.chromium.org/114050
url_canon: New CanonicalizeHostVerbose() function.
This function allows the caller to distinguish between 4 cases:
- A valid, canonical IPv4 address.
- A valid, canonical IPv6 address.
- A "broken" address. This is something which kinda almost looks like an IP
address, but has been deemed to be invalid. For IPv4, this indicates a
numerical component which is longer than 16 digits, or one which can't be
used without truncation/overflow. For IPv6, this is any non-parseable
address containing a colon or square brackets.
- "neutral". This indicates that the output doesn't really look like an
IP address at all, and should probably be treated as a hostname.
The CanonHostInfo struct is meant to be extensible. In addition to the 4 cases
above, it also returns the number of components used to make an IPv4 address,
which will be useful to Chromium, and will make it possible stop exposing
FindIPv4Components.
This is the first step toward making Chrome behave better for these cases:
- http://[www.google.com]/
- http://192.168.0.0000000000000000000000000001/
- http://192.168.0.99999/
Edit:
- Changed the signature of CanonicalizeIPAddress(), instead of creating
a new "Verbose" version.
- For completeness, now includes the CanonicalizeHost() changes,
with an extended-output CanonicalizeHostVerbose(), because some callers
only care whether the canonicalization was a success or not.
Code review:
http://codereview.chromium.org/114050
-
issue 8
(StandardURL containing a "#" in the password gets mis-parsed) commented on by vega.james
-
-
issue 8
(StandardURL containing a "#" in the password gets mis-parsed) Status changed by brettw
-
-
issue 8
(StandardURL containing a "#" in the password gets mis-parsed) reported by vega.james
-
-
r106
(url_parse: Segment partially-typed IPv6 literals.
In Chromi...) committed by pmarks@google.com
- url_parse: Segment partially-typed IPv6 literals.
In Chromium, when a user is typing an IPv6 literal into the address bar, the
autocomplete system goes nuts, trying to grab a port from the end of the
address before it's complete.
Fix this by parsing unterminated IPv6 literals as if there were no port number.
These partial addresses will not survive canonicalization, but they keep the
autocompleter running smoothly as the address is typed.
Also, fix some minor lint warnings elsewhere in url_parse.cc
Code review:
http://codereview.chromium.org/115748
url_parse: Segment partially-typed IPv6 literals.
In Chromium, when a user is typing an IPv6 literal into the address bar, the
autocomplete system goes nuts, trying to grab a port from the end of the
address before it's complete.
Fix this by parsing unterminated IPv6 literals as if there were no port number.
These partial addresses will not survive canonicalization, but they keep the
autocompleter running smoothly as the address is typed.
Also, fix some minor lint warnings elsewhere in url_parse.cc
Code review:
http://codereview.chromium.org/115748
-
r105
(Move ICU dependent function ReadUTFChar into the icu.cc file...) committed by brettw
- Move ICU dependent function ReadUTFChar into the icu.cc file. This avoids icu
dependency in other object files that use inline functions from
url_canon_internal.h.
Patch by tommi@chromium.org.
Review: http://codereview.chromium.org/118062
Move ICU dependent function ReadUTFChar into the icu.cc file. This avoids icu
dependency in other object files that use inline functions from
url_canon_internal.h.
Patch by tommi@chromium.org.
Review: http://codereview.chromium.org/118062
-
-
-
-
-
r102
(A URL can contain an IPv6 address literal, like [2001:db8::2...) committed by brettw
- A URL can contain an IPv6 address literal, like [2001:db8::2]. Users of
the GURL library sometimes need the square brackets, and sometimes don't.
Checked in for Paul Marks
Review URL: http://codereview.chromium.org/113187
A URL can contain an IPv6 address literal, like [2001:db8::2]. Users of
the GURL library sometimes need the square brackets, and sometimes don't.
Checked in for Paul Marks
Review URL: http://codereview.chromium.org/113187
-
-
-
-
issue 2
(IPv6 string literals need canonicalization) commented on by brettw
-
-
-
issue 2
(IPv6 string literals need canonicalization) commented on by sparkmaul
-
-
issue 2
(IPv6 string literals need canonicalization) commented on by brettw
-
-
-
-
-
issue 7
(GURL: add a PlainHost() method for bracketless IPv6 literals...) commented on by sparkmaul
-
-
-
-
-
-
|
