cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: FW: Malformed stream: Read timed out
Date Wed, 12 Oct 2005 17:21:41 GMT
On Wednesday 12 October 2005 22:18, Steven Noels wrote:

> > I have very mysterious error while using forms with
> > @enctype="multipart/form-data". _Some times_ while submiting the form
> > I get "org.apache.cocoon.servlet.multipart.MultipartException:
> > Malformed stream: Read timed" out error and have no idea what is the
> > cause. 

I am sure that there can be several answer to this, let me run one very 
obscure that I came across last week.

> > but only if size of form data being submited to a server 
> > is big enough (about 2000b). 

I sit on a PPP link for my broadband, and that link has a maximum packet size 
of 1400 something bytes, and not the typical 1500 bytes.
I have noticed an increasing number of websites that I can no longer reach. 
And the problem is not even mine, it is described in Debian documentation 
with a note about "criminally braindead network administrators".

This is what happens;

 1. The server sends the response to me.
 2. Each packet (1500 bytes) is marked "Do not fragment", which is becoming
    increasingly common.
 3. When the packet comes to the router near me, it sees "Ah. Too big. Ah.
    Don't fragment." so it sends back an ICMP packet saying "Too big."
 4. Some last-mile ISP or IT department has decided to block ICMP traffic.
 5. The server never sees the "Too Big" message, and thinks the packet was
    lost. It retries.
 6. A timeout happens sooner or later.

And of course, pages that are small enough to fit into the 1400bytes packet, 
comes through without problems.

In the cases where we control the server, we have two solutions for this;

  1. Disable the "PMTU detection", by setting "1" in the file below;
     echo "1" >/proc/sys/net/ipv4/ip_no_pmtu_disc 

  2. Make the max MTU size smaller by modifying the ethernet interface. On
     Debian that is /etc/network/interfaces and adding MTU 1400 under the
     iface of the relevant interface, normally eth0.

I think the above is so obscure that it may catch many software developers by 
surprise, since they are normally the one to blame, and we couldn't have a 

I hope you can manage to rule this in or out, for your particular case.


View raw message