Sorry, that was incorrect - the api call is on the exchange, but it get/sets
the attributes on the related context.
This seems wrong to me as well, and I’ll probably change it in the robaho
version, but this would be a breaking change with the JDK implementation.
I agree with Ethan, that I thin
I am confused though - I reviewed the robaho source code which came from the
JDK, and the setAttribute is on the exchange, which is per request, not per
context.
> On Dec 6, 2024, at 8:41 AM, robert engels wrote:
>
> In minor defense of the JDK (I am worried more about ambiguity) - I’ve seen
In minor defense of the JDK (I am worried more about ambiguity) - I’ve seen the
JDK users implement this by add to the request headers - but with the JDK
making this read-only, this is no longer possible, so the get/set attribute is
the only viable way to pass per request information between lay
After mulling it over some more, I think that as is there is actually
no valid use for .setAttribute as implemented by the JDK
Even the most trivial usages of it are broken under moderate load. This
includes the usage in SimpleFileServer.createOutputFilter and
SimpleFileServer.createFileHandler
i
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("CURREN
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 t
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 {@co
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 M
