Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #2192 - honor addr%scopeid ipv6 notation #2395

Merged
merged 1 commit into from
Sep 29, 2023
Merged

Fix #2192 - honor addr%scopeid ipv6 notation #2395

merged 1 commit into from
Sep 29, 2023

Conversation

cpq
Copy link
Member

@cpq cpq commented Sep 29, 2023

No description provided.

@cpq cpq requested a review from scaprile September 29, 2023 14:11
@cpq cpq force-pushed the scopeid branch 2 times, most recently from de95185 to 1cd55e9 Compare September 29, 2023 14:18
src/net.c Show resolved Hide resolved
@cpq cpq merged commit 5ebede5 into master Sep 29, 2023
47 of 115 checks passed
@cpq cpq deleted the scopeid branch September 29, 2023 14:52
@comburent
Copy link

Apologies for chiming in late, the % has to be percent-encoded as @scaprile already pointed out in #2192 (comment).

Looking at the ASSERT(…) additions to the test/unit_test.c this doesn't seem to be what's happening here.

@cpq
Copy link
Member Author

cpq commented Oct 2, 2023

@comburent could you provide a couple of examples please?

@comburent
Copy link

@comburent could you provide a couple of examples please?

Sure, here are some examples:

http://[fe80::1%251]:8000  => zone-id is 1.
http://[2001:db8:1234%25255]:8000  => zone-id is 255.

These are described in RFC6874 if you're interested in further information.
Curiously they also make this suggestion:

It is desirable for all browsers to recognise a ZoneID preceded by a
percent-encoded "%". In the spirit of "be liberal with what you
accept", we also suggest that URI parsers accept bare "%" signs when
possible (i.e., a "%" not followed by two valid and meaningful
hexadecimal characters). This would make it possible for a user to
copy and paste a string such as "fe80::a%en1" from the output of a
"ping" command and have it work. On the other hand, "%ee1" would
need to be manually rewritten to "fe80::a%25ee1" to avoid any risk of
misinterpretation.

Though this doesn't matter since this applies for interface names which we agreed to leave them out in #2192 (comment).

@comburent
Copy link

^^ ping @cpq

@cpq
Copy link
Member Author

cpq commented Oct 14, 2023

Uh, sorry, missed a notification for this.

So, basically, the current logic is bad since we treat the %xx scope_id suffix as-is, like %31 gives scope_id == 31
Whereas we must treat it as a URL-encoded value, thus %31 should give scope_id == 1 (1 has ASCII code 0x31).

Can you confirm please?

@comburent
Copy link

So, basically, the current logic is bad since we treat the %xx scope_id suffix as-is, like %31 gives scope_id == 31 (…)

Yes.

(…) Whereas we must treat it as a URL-encoded value, thus %31 should give scope_id == 1 (1 has ASCII code 0x31).

No since URL-encoded %31 would decode as a bare 1. (e.g. 2001:db8::432%31 URL-decodes to 2001:db8::4321 which we clearly see that there's no scope-id here, it's just a different way of typing the same thing)

The % character itself is what needs to be percent-encoded, so the URL-encoded %25xx should give xx as scope-id. (e.g. %251 is URL-decoded to %1 which means that scope_id == 1, as shown in the examples at #2395 (comment))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants