hi
Brian Moseley wrote:
Angela Schreiber wrote:
from my understanding the contentlength is therefore -1 if the
request body is sent 'chunked' as defined by http 1.1
ah, yeah, could be. i haven't ever used chunked, so i'm not educated
about it.
see RFC 2616:
- 3.6 Transfer Codings
- 4.4 Message Length
- 14.13 Content-Length
[...] Content-Length SHOULD be sent unless this is prohibited by the
rules in section 4.4. [...]
due to this 'SHOULD' i don't suggest to add a check for
Content-Length OR Transfer-Encoding.
for this reason i checked for the inputstream not being null
and did not check the content-length. what do you think?
before my change, there were many spurious debug "Unable to build an
XML Document from the request body" messages that polluted my debug
log and freaked out my system administrators. it seemed as if this
method was trying to parse xml off an input stream that had no data to
be read.
maybe there's a better way to short circuit parsing when there's no
data. perhaps InputStream.available()?
hm.... java api states:
"The available method for class InputStream always returns 0.
This method should be overridden by subclasses."
to be honest, i would rather not rely this 'should'. i quickly
discussed it with dominique and he didn't look so confident
about the 'available' either.
angela, thoughts?
sure. always. but sometimes i prefer not to share them ;)
to come to a conclusion: the reason why you added the check
is your system administrator being frightend by 'DEBUG' messages
in the log file. you may set the log-level to 'WARN'... alternatively
we comment the log output until i have time to think about
yet another suggestion. it doesn't see the need for a immediate
action regarding this issue.
thanks
angela
