On Wed, 17 Dec 2025 11:51:04 GMT, Daniel Fuchs <[email protected]> wrote:

>> The first byte of a SSL ClientHello handshake record is 0x16 (22).
>> If the first byte received on a HTTP/1.1 clear connection is 0x16, the HTTP 
>> server could fail fast, return 400 bad request and immediately close the 
>> connection.
>> 
>> This changeset extends the fail fast behaviour for other ineligible bytes, 
>> such as any byte corresponding to ASCII characters <= 31.
>
> Daniel Fuchs has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains 10 additional 
> commits since the last revision:
> 
>  - .toString() is not needed
>  - Review feedback: improved logging
>  - Merge branch 'master' into ClearTextSSL-8373677
>  - Update test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java
>    
>    Co-authored-by: Andrey Turbanov <[email protected]>
>  - Update src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java
>    
>    Co-authored-by: Andrey Turbanov <[email protected]>
>  - minor test fix - unused import + obsolete comment
>  - fix whitespace
>  - fix copyright year in test
>  - add bug id to test
>  - 8373677: Clear text HttpServer connection could fail fast if receiving SSL 
> ClientHello

src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java line 119:

> 117:                             throw new ProtocolException("Unexpected 
> start of request line");
> 118:                         }
> 119:                         offset++;

The changes look good to me. It took me a while to understand what this 
`offset` was and how those increments are used. It looks like it behaves merely 
like a boolean to decide whether or not to check the byte against the 
`FIRST_CHAR`. Maybe we could change `int offset` to `boolean firstByteChecked = 
false;`. It's also OK if you like to leave it in the current form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28827#discussion_r2626792411

Reply via email to