wy471x commented on PR #6456: URL: https://github.com/apache/shenyu/pull/6456#issuecomment-5153040846
> I found a compatibility issue in the IPv6 URL handling. > > This PR changes the canonical serialized IPv6 upstream URL from the old bare form (`host:port`) to bracketed form (`[host]:port`) in `CommonUpstreamUtils.buildUrl(...)`. However, discovery persistence, dedupe, status updates, and deletes still use exact `upstream_url` string matching. > > That means an existing persisted IPv6 upstream written by older code, for example `2001:db8::1:8080`, will not match the new `[2001:db8::1]:8080` value after upgrade. `nativeCreateOrUpdate(...)` can insert a duplicate instead of updating the old row, and status/delete paths can leave the old row stale because the SQL and in-memory comparisons still key on exact `upstream_url`. > > There are a few parser edge cases worth covering at the same time: > > * Bare IPv6 without brackets, e.g. `2001:db8::1`, is split on the last colon and becomes host `2001:db8:` + port `1`. > * Already bracketed host input passed to `buildUrl`, e.g. `[2001:db8::1]`, becomes `[[2001:db8::1]]:8080`. > * Bracketed malformed input like `[2001:db8::1` throws a low-level `StringIndexOutOfBoundsException`, while `[2001:db8::1]junk` is silently accepted as port 80. > > Could we add an upgrade-safe canonicalization strategy here, either by migrating old `upstream_url` values to the new bracketed form or by making lookup/update/delete/dedupe tolerant of both legacy and canonical forms until data is normalized? Tests for legacy bare IPv6 rows plus the malformed parser cases would catch the risky paths. I have fixed the issues you mentioned. Please take a look when you have time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
