[parker89]

Follow-up to #915. RequestSupport#extractPathPrefix currently treats any . in the path as needing normalization, so paths with dotted segments or file extensions (/packages/com.example.service/versions/1.2.3, /files/report.csv) still go through segment decoding, dot segment removal and re-encoding.

A . can only begin a dot segment if it is the first character of a segment, so this only flags a . that follows a / or starts the path. Dots anywhere else can't change the result.

The output is unchanged. The existing tests pass, and I added tests for dots inside segments as well as for dot segments that still have to be normalized (/./, a trailing ., %2E%2E and a leading ../). I also compared it with the current implementation on 200k generated paths starting with / and got identical results.

JMH, JDK 21, average time and gc.alloc.rate.norm:

Request target	master ns/op	this ns/op	master B/op	this B/op
/api/v1/packages/com.example.service/versions/1.2.3?... (3 params)	1,308	106 (-92%)	3,136	184 (-94%)
/api/v2/datasets/<uuid>/files/report.csv?... (3 params)	1,571	135 (-91%)	3,352	216 (-94%)
paths without dots (no query, 3, 6 and 10 params)	40-140	unchanged	56-216	unchanged

[ok2c]

@parker89 Looks good to me.

[arturobernalg]

The optimization looks good, but it changes the path prefix for rootless paths containing dots.

For foo.bar/baz, master returns /foo.bar/, while this change returns foo.bar/.

Although this is not a valid HTTP/1.1 origin-form, it changes the authentication cache behavior. I think we should preserve the existing behavior here.

[ok2c]

@arturobernalg The culprit are my previous changes that have already been merged in, not this change-set

        Assertions.assertEquals("/aaaa/", RequestSupport.extractPathPrefix(new BasicHttpRequest("GET", "aaaa/bbbb")));
        Assertions.assertEquals("/aaaa/", RequestSupport.extractPathPrefix(new BasicHttpRequest("GET", "aaaa/b.b.b.b")));

Presently the behavior of the method is inconsistent and the first assert fails with the current master. I am going to fix it. This change-set can be merged as is, in my opinion.

[ok2c]

@arturobernalg Fixed with e040ff3

@parker89 Please rebase your change and will merge it.

[parker89]

Rebased. Should be mergeable now.

[ok2c]

cherry-picked to 5.6.x