Jason Hunter wrote:
>
> > I believe the call to setBufferSize should have the ability to
> > return the actual buffer size allocated, which may be more *or less*
> > than that requested. This would allow the container to balance buffer
> > allocation between servlets, and to
> > refuse outrageously large buffer requests from broken, malicious or
> > badly coded servlets.
>
> If my servlet's malicious, or if I'm a poor coder, then I can still do
>
> byte[] buf = new byte[HUGE_VALUE]
>
> to chew the server.
True, of course.
> Because the server must follow the setBufferSize() request, it makes
> it a lot easier to write portable code. It's not just a performance
> question, it's an issue of how much output a servlet can write and
> still reset the response with an error code.
I would question just *how* much easier it makes it ;) However, with your first
argument you are encouraging a particular programming model, and implementing it
in the server: write whatever you like, you can always wipe it later and start
again.
In that case, the servlet programmer should be encouraged to buffer the data
internally, rather than rely on an external agency, which has an unknown
implementation and performance.
But I accept your point about needing to return an error code having already
written some data. But surely it would be a lot cleaner for the container to
provide an automatically 'infinite' buffer, and a commit function call.
Most of the servlets I have written generally havn't known when an error could
occur, and so I coudn't have set the buffer size in advance unless it was always
to the total size of my output. And similarly, in a lot of cases, I don't know
that size in advance.
It seems to me it has to be all or nothing. I don't see the advantage of setting
the buffer to a particular size, since many servlets are creating dynamic
output. If we wish to support the ability to change error code, then the buffer
should be 'infinite'.
jon
--
Jon Saville
Principle Member of Technical Staff - IP Telephony Program Manager
# The opinions expressed in this message are my own and do not
# represent the opinions of others or Signals & Software company policy.
Signals+Software Ltd Tel: +44 (0)20 8 872 9000
The Heights, Lowlands Road Fax: +44 (0)20 8 872 9001
Harrow, Middx, HA1 3AW, UK Web: www.sasl.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
