Martin,
I'm torn between thinking: - "there are many ways to do this, so why should
we pick one? Isn't this a framework's job" vs "We've picked lots of
other 'favourite' solutions in the spec, so we should do this as well".
If we want to support this, then your Option 1 is OK other than its lack of
flow control (see below), but I don't like your Option 2 because of the
size issues (plus Option 2 is easy to implement using Option 1 if somebody
has no size concerns). Note that either solution should deliver
Strings rather than bytes[].
But just to show that there are many ways to skin this cat, here is an
experiment we've done with the reactive streams API that will be in Java 9,
that consumes an async stream of ByteBuffer and produces and async stream
of Fields.Field (this is equivalent to your Option 1)
https://github.com/jetty-project/jetty-reactive/blob/master/src/main/java/org/eclipse/jetty/reactive/FormFieldProcessor.java
And here is a similar reactive stream that does your Option 2:
https://github.com/jetty-project/jetty-reactive/blob/master/src/main/java/org/eclipse/jetty/reactive/FormProcessor.java
The good thing about the reactive stream approach over your listener
approach is that it allows back pressure to be applied. Imagine a
client sending a massive form with many many fields. With your option 1,
there is no way for the field consumer to slow the delivery of those
fields, potentially causing either TCP/IP or HTTP2 flow control to slow the
sending of those fields at source.
With reactive streams, the needs for request(int n) signals provides a back
pressure mechanism that can can trigger flow control.
I've still not used reactive streams enough to say I actually like them....
but they are destined for the JDK... so perhaps they are a good choice even
if we don't luv em?
cheers
On 2 December 2015 at 10:12, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
> With the introduction of async i/o in Servlet 3.1 it is now possible for
> applications to read post data asynchronously. However applications which
> process parameters sent as post data can only take advantage of async i/o
> if they are willing to parse the parameters themselves without use of the
> convenience methods provided by ServletRequest.
>
> I propose this is addressed and we provide a method for applications to
> receive parameters as post data using async i/o without having to do their
> own parsing. There are many ways to do this. My suggestions are:
>
> Option 1. Add a new parameterListener object with methods
> onParameterAvailable, onAllParametersRead, and onError (same equivalent
> methods as a readListener). It could be registered with the input stream
> just like readListener.
>
> Option 2: Add a new method ServletRequest.addParameters(byte[][]
> parameterBytes) This can then be called by the application's readListener
> once it has received all of the post data.
>
> Thank you,
> Martin Mulholland.
> WebSphere Application Server Web Tier Architect
> email: mmulholl_at_us.ibm.com
>
> IBM RTP, PO BOX 12195, 503/C227,
> 3039 Cornwallis Rd, RTP, NC 27709-2195
> t/l 444-4319, external (919)-254-4319
>
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com