You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Philippe Khalife <pk...@dinmar.com> on 2001/10/19 17:31:59 UTC
MOD_WEBAPP & Gzip'ed or Object Streams, Error: Invalid WARP packet type for body
This is what I'm running.
TC4,
Apache1.3.22
Mod_webapp
I'm having the same problem on Solaris, Linux, and Win2000
I have Servlet that produces output that is either HTML and browser bound or
to communicate with an Applet using Object input/output streams and it works
fine using a gzip'd stream as well, but under the HttpConnector only
Under the Warp Connector, Servlet->Browser Works fine if the output is
gzip'd or not.
But Servlet->Applet does not, I was getting errors that the stream is
missing the required headers for Gzip to work.
So I disabled the gzip'd stream, the application moves a little further but
Catalina is throwing this error:
java.io.IOException: Invalid WARP packet type for body
at
org.apache.catalina.connector.warp.WarpRequest$Stream.read(Unknown So
urce)
at
org.apache.catalina.connector.warp.WarpRequest$Stream.read(Unknown So
urce)
at org.apache.catalina.connector.RequestStream.read(Unknown Source)
at org.apache.catalina.connector.RequestStream.close(Unknown Source)
at java.io.ObjectInputStream.close(ObjectInputStream.java:1874)
.....
If anyone has seen this before, or knows what it might be I would really
appreciate your response.
Thanks you,
Philippe.
------------------------- CODE Sample -----------------------------
// Servlet Side
//GZIPInputStream gzin = new
GZIPInputStream(request.getInputStream());
//in = new ObjectInputStream(gzin);
in = new ObjectInputStream(request.getInputStream() );
//GZIPOutputStream gzout = new
GZIPOutputStream(response.getOutputStream());
//out = new ObjectOutputStream(gzout);
out = new
ObjectOutputStream(response.getOutputStream());
// Applet Side
// Obtain the connection output stream
OutputStream os = con.getOutputStream();
// Build a Gzip'd output stream on top of the Connection Output
Stream
// java.util.zip.GZIPOutputStream gzout = new
java.util.zip.GZIPOutputStream(os);
// Get the Object Output Stream form the Gzip'd output stream
//ObjectOutputStream out = new ObjectOutputStream(gzout);
// No Compressioon
ObjectOutputStream out = new ObjectOutputStream(os);
// Get the input Stream
InputStream is = con.getInputStream();
// Build the Gzip'd input stream on top the Connection input stream
//java.util.zip.GZIPInputStream gzin = new
java.util.zip.GZIPInputStream(is);
//ObjectInputStream in = new ObjectInputStream( gzin );
// No Compression
ObjectInputStream in = new ObjectInputStream( is );
------------------------------------------------------
The error I'm getting is this:
MOD_WEBAPP, TC4, APACHE1.3.22, MOD_SSL, ATT: Pier
Posted by Philippe Khalife <pk...@dinmar.com>.
MOD_WEBAPP, TC4, APACHE1.3.22, MOD_SSL, Solaris2.6 (After much ado about
nothing to get Apache,SSL, +DSO)
I've hit the wall with MOD_WEBAPP & SSL.
So a few issues to report:
On the latest nighly build webapp-module-20011030
1)
java/WarpConnector.java has
import org.apache.catalina.ServerSocketFactory;
Instead of
import org.apache.catalina.net.ServerSocketFactory;
2) Now it's up and running, apachectl start (no ssl) the connector works
fine.
but after an apachectl startssl, I get this error on any connection
attempt.
2001-10-30 23:39:02 [org.apache.catalina.connector.warp.WarpConnector]
Connection from localhost/127.0.0.1:37560 to localhost/127.0.0.1:10003
2001-10-30 23:39:02
[org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter
mappings (4)
2001-10-30 23:39:05 [org.apache.catalina.connector.warp.WarpConnection]
Exception on socket
java.io.IOException: Premature packet header end
at
org.apache.catalina.connector.warp.WarpConnection.recv(WarpConnection.java:2
37)
at
org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHand
ler.java:112)
at
org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java:19
4)
at java.lang.Thread.run(Thread.java:484)
So I tried compiling source from CVS, maybe there's a fix in there:
Now the connector works fine without SSL, and only partially in SSL mode.
Basically Gzip'd or Object Streams fail to connect, while regular browser
requests go through. I know this problem was fixed before, but it seems to
be broken in SSL mode.
As always your replies are greatly appreciated,
Is there anything I can read about SSL & MOD_WEBAPP?
Thanks,
PK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: MOD_WEBAPP & Gzip'ed or Object Streams, Error: Invalid WARP
packet type for body
Posted by Pier Fumagalli <pi...@betaversion.org>.
Philippe Khalife at pkhalife@dinmar.com wrote:
>
> This is what I'm running.
>
> TC4,
> Apache1.3.22
> Mod_webapp
>
> I'm having the same problem on Solaris, Linux, and Win2000
>
> I have Servlet that produces output that is either HTML and browser bound or
> to communicate with an Applet using Object input/output streams and it works
> fine using a gzip'd stream as well, but under the HttpConnector only
>
> Under the Warp Connector, Servlet->Browser Works fine if the output is
> gzip'd or not.
>
> But Servlet->Applet does not, I was getting errors that the stream is
> missing the required headers for Gzip to work.
> So I disabled the gzip'd stream, the application moves a little further but
> Catalina is throwing this error:
>
> java.io.IOException: Invalid WARP packet type for body
> at
> org.apache.catalina.connector.warp.WarpRequest$Stream.read(Unknown So
> urce)
> at
> org.apache.catalina.connector.warp.WarpRequest$Stream.read(Unknown So
> urce)
> at org.apache.catalina.connector.RequestStream.read(Unknown Source)
> at org.apache.catalina.connector.RequestStream.close(Unknown Source)
> at java.io.ObjectInputStream.close(ObjectInputStream.java:1874)
> .....
>
> If anyone has seen this before, or knows what it might be I would really
> appreciate your response.
I'm fixing it right now (see this bug entry in the database):
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3534
I found a way to reproduce it, and it is not looking that hard... Should be
fixed in the next daily snapshot..
Pier