You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2020/06/05 12:21:58 UTC

[tomcat] branch master updated: Ignore exception getting content length

This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
     new e8bcbf1  Ignore exception getting content length
e8bcbf1 is described below

commit e8bcbf1a017e598498343ebd05f77f07934910bb
Author: remm <re...@apache.org>
AuthorDate: Fri Jun 5 14:21:39 2020 +0200

    Ignore exception getting content length
    
    If the value is invalid, there will be another attempt to convert the
    number with no really easy way out. Ignore the exception which already
    happened in prepareRequest.
---
 java/org/apache/coyote/http11/Http11Processor.java | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/coyote/http11/Http11Processor.java b/java/org/apache/coyote/http11/Http11Processor.java
index 897c2d9..00469e1 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -528,8 +528,16 @@ public class Http11Processor extends AbstractProcessor {
 
 
     private void checkMaxSwallowSize() {
-        if (request.getContentLengthLong() > 0 &&
-                (request.getContentLengthLong() - request.getBytesRead() > protocol.getMaxSwallowSize())) {
+        // Parse content-length header
+        long contentLength = -1;
+        try {
+            contentLength = request.getContentLengthLong();
+        } catch (Exception e) {
+            // Ignore, an error here is already processed in prepareRequest
+            // but is done again since the content length is still -1
+        }
+        if (contentLength > 0 &&
+                (contentLength - request.getBytesRead() > protocol.getMaxSwallowSize())) {
             // There is more data to swallow than Tomcat will accept so the
             // connection is going to be closed. Disable keep-alive which will
             // trigger adding the "Connection: close" header if not already


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [tomcat] branch master updated: Ignore exception getting content length

Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Jun 5, 2020 at 5:59 PM Mark Thomas <ma...@apache.org> wrote:

> On 05/06/2020 13:21, remm@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >      new e8bcbf1  Ignore exception getting content length
> > e8bcbf1 is described below
> >
> > commit e8bcbf1a017e598498343ebd05f77f07934910bb
> > Author: remm <re...@apache.org>
> > AuthorDate: Fri Jun 5 14:21:39 2020 +0200
> >
> >     Ignore exception getting content length
> >
> >     If the value is invalid, there will be another attempt to convert the
> >     number with no really easy way out. Ignore the exception which
> already
> >     happened in prepareRequest.
>
> Thanks for catching this.
>
> I think it would be useful to cache the fact that the header had been
> parsed (or not found) to save looping through the headers again.
>
> What do you think to switching to Long and using:
> - null -> not yet parsed
> - -1   -> known that no valid value is present
> - >=0  -> the parsed value of the header
>
> The alternative is a boolean flag. Long seems cleaner to me even if it
> is slightly more memory.
>
> Thoughts?
>

If you want to, but it's processed twice only if there's a problem so the
cost is minimal.

Rémy

Re: [tomcat] branch master updated: Ignore exception getting content length

Posted by Mark Thomas <ma...@apache.org>.
On 05/06/2020 13:21, remm@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>      new e8bcbf1  Ignore exception getting content length
> e8bcbf1 is described below
> 
> commit e8bcbf1a017e598498343ebd05f77f07934910bb
> Author: remm <re...@apache.org>
> AuthorDate: Fri Jun 5 14:21:39 2020 +0200
> 
>     Ignore exception getting content length
>     
>     If the value is invalid, there will be another attempt to convert the
>     number with no really easy way out. Ignore the exception which already
>     happened in prepareRequest.

Thanks for catching this.

I think it would be useful to cache the fact that the header had been
parsed (or not found) to save looping through the headers again.

What do you think to switching to Long and using:
- null -> not yet parsed
- -1   -> known that no valid value is present
- >=0  -> the parsed value of the header

The alternative is a boolean flag. Long seems cleaner to me even if it
is slightly more memory.

Thoughts?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org