Javadoc change in HttpExchange makes external implementations non-complaint

[Ethan McCue]

Sorry, meant to send this to the list:

I will add as maybe obvious context that the way the JDK currently
implements this is (I think, correct me if I am wrong) a security
nightmare. That it might not be obvious (or uniform across an ecosystem of
implementations) that exchange.setAttribute("CURRENTLY_AUTHENTICATED_USER",
"..."); will not actually be setting an attribute on the exchange, but
instead a global thing, *is **an issue*

If this is a deliberate choice in the existing implementation, I am curious
to know how it came about.

On Thu, Dec 5, 2024 at 11:13 PM Robert Engels <rengels at ix.netcom.com> wrote:

> Hi,
>
> I read the bug report. I don’t think this is sufficient. This is a
> specification so in order to have compliant behavior no matter the
> implementation there cannot be a different set of rules for the reference
> implementation vs others.
>
> So the api should be clarified in a non ambiguous manner and then one or
> more implementations can be classified as non compliant.
>
> Robert
>
> On Dec 5, 2024, at 6:31 AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>
> 
>
> Hello Ethan,
>
> Thank you for noticing this and bringing this up here. I've raised
> https://bugs.openjdk.org/browse/JDK-8345577 and we will address this
> shortly.
>
> -Jaikiran
> On 05/12/24 3:22 am, Ethan McCue wrote:
>
> Sorry
>
> Before:
>
>      * {@link Filter} modules may store arbitrary objects with {@code
> HttpExchange}
>      * instances as an out-of-band communication mechanism. Other filters
>      * or the exchange handler may then access these objects.
>
> Bungled the copy-paste
>
> On Thu, Dec 5, 2024 at 6:49 AM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Hi all,
>>
>> This change (
>> https://github.com/openjdk/jdk/commit/40ae4699622cca72830acd146b7b5c4efd5a43ec)
>> makes the Jetty implementation of the SPI be no longer fit the Javadoc.
>>
>> HttpContexts are not per-request while the previous Javadoc implied that
>> the attribute mechanism on exchanges was.
>>
>> Before:
>>
>>      * Sets an attribute with the given {@code name} and {@code value} in
>> this exchange's
>>      * {@linkplain HttpContext#getAttributes() context attributes}.
>>      * or the exchange handler may then access these objects.
>>
>> After:
>>
>>      * Sets an attribute with the given {@code name} and {@code value} in
>> this exchange's
>>      * {@linkplain HttpContext#getAttributes() context attributes}.
>>      *
>>      * @apiNote {@link Filter} modules may store arbitrary objects as
>> attributes through
>>      * {@code HttpExchange} instances as an out-of-band communication
>> mechanism. Other filters
>>      * or the exchange handler may then access these objects.
>>
>> The Jetty implementation, I think rightfully, assumed that this context
>> was per-request and implemented it as so.
>>
>>
>> https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-core/jetty-http-spi/src/main/java/org/eclipse/jetty/http/spi/JettyHttpExchangeDelegate.java#L223
>>
>> As such, I don't think simply a javadoc change as a resolution to these
>> issues is applicable
>>
>> https://bugs.openjdk.org/browse/JDK-8345233
>> https://bugs.openjdk.org/browse/JDK-8235786
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20241205/0b31d955/attachment.htm>