You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by bc...@apache.org on 2005/12/07 18:43:58 UTC
svn commit: r354815 -
/incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Author: bcm
Date: Wed Dec 7 09:43:54 2005
New Revision: 354815
URL: http://svn.apache.org/viewcvs?rev=354815&view=rev
Log:
only attempt to read from the http request's input stream if the
client specified a positive content length. this avoids io exceptions
being written to the debug stream when we know the input stream should
not have any content.
Modified:
incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Modified: incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
URL: http://svn.apache.org/viewcvs/incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java?rev=354815&r1=354814&r2=354815&view=diff
==============================================================================
--- incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java (original)
+++ incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java Wed Dec 7 09:43:54 2005
@@ -260,17 +260,23 @@
*/
public Document getRequestDocument() {
Document requestDocument = null;
- // try to parse the request body
- try {
- InputStream in = httpRequest.getInputStream();
- if (in != null) {
- SAXBuilder builder = new SAXBuilder(false);
- requestDocument = builder.build(in);
+ if (httpRequest.getContentLength() > 0) {
+ // try to parse the request body
+ try {
+ InputStream in = httpRequest.getInputStream();
+ if (in != null) {
+ SAXBuilder builder = new SAXBuilder(false);
+ requestDocument = builder.build(in);
+ }
+ } catch (IOException e) {
+ if (log.isDebugEnabled()) {
+ log.debug("Unable to build an XML Document from the request body: " + e.getMessage());
+ }
+ } catch (JDOMException e) {
+ if (log.isDebugEnabled()) {
+ log.debug("Unable to build an XML Document from the request body: " + e.getMessage());
+ }
}
- } catch (IOException e) {
- log.debug("Unable to build an XML Document from the request body: " + e.getMessage());
- } catch (JDOMException e) {
- log.debug("Unable to build an XML Document from the request body: " + e.getMessage());
}
return requestDocument;
}
Re: svn commit: r354815 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> 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
i certainly could do that, but i'm wary of adding
exceptional cases to logging config every time a single
class outputs a log statement that i don't want to see in
normal operation. that could mask other log statements
emanating from the same class that i *do* want to see.
> 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.
there is no need for immediate action on any of these
issues. i have imported specific revisions of jackrabbit
into the osaf svn repository and can maintain whatever
changes i need there without attempting to push them back
into the asf repository when they aren't wanted.
it would be nice to understand why an exception is thrown at
this location in the code during normal operation of the
server. this behavior points to something being not quite
correct with the implementation. but as i don't have any
other suggestions to make, i won't press the issue.
Re: svn commit: r354815 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Posted by Angela Schreiber <an...@day.com>.
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
Re: svn commit: r354815 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Posted by Brian Moseley <bc...@osafoundation.org>.
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.
>
>> 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()?
angela, thoughts?
Re: svn commit: r354815 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> sorry... me again...
don't be sorry - keep me honest! :)
> 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.
> 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()?
Re: svn commit: r354815 - /incubator/jackrabbit/trunk/contrib/jcr-server/webdav/src/java/org/apache/jackrabbit/webdav/WebdavRequestImpl.java
Posted by Angela Schreiber <an...@day.com>.
hi brian
sorry... me again...
bcm@apache.org wrote:
> Author: bcm
> Date: Wed Dec 7 09:43:54 2005
> New Revision: 354815
>
> URL: http://svn.apache.org/viewcvs?rev=354815&view=rev
> Log:
> only attempt to read from the http request's input stream if the
> client specified a positive content length. this avoids io exceptions
> being written to the debug stream when we know the input stream should
> not have any content.
again i'm not conviced you are correct.
the 'HttpServlet' interface defines the following for the
getContentLength method:
getContentLength()
Returns the length, in bytes, of the request body and made available by
the input stream, or -1 if the length is not known. For HTTP servlets,
same as the value of the CGI variable CONTENT_LENGTH.
from my understanding the contentlength is therefore -1 if the
request body is sent 'chunked' as defined by http 1.1
for this reason i checked for the inputstream not being null
and did not check the content-length. what do you think?
regards
angela