We have a very similar situation. One of our screens let's a user paste
html into a text area. They can then post the form and the html will
previewed for them. They then hit the back button and can either submit the
html or edit and re-preview. When using iPlanet as the webserver this works
fine, however using the JRun webserver the second post (either the submit or
preview) always results in a "Short Read" exception.
I looked around on the web and it appears the problem is in the
parseFormData() method of HttpUtils which tries to read from the inputstream
but the stream is not the same length as the content-length and the
exception occurs. The JRun webserver then appears to die. This appears to
be because the input stream is not being recreated. If the user waited a
couple minutes, such as copying the html into Frontpage and re-work it, then
pasted it back, it works fine. The odd thing is it works with iPlanet, but
not with the JRun webserver.
I think I've brought this up before but never saw any follow up as the
Allaire folk keep saying the JRun web server is to be used for development
only. That being said, is there any way to force the creation of a new
input stream for each post regardless if the page was already posted once.
The alternative is to forward back to the page from the preview page, but
since a lot parameters are being passed around I'm not sure how to best
achieve that and keep all the changes the user made.
thanks,
brian
-----Original Message-----
From: Jeff Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 1:22 PM
To: JRun-Talk
Subject: Form Caching Question
I don't know as this relates directly to JRun but we are experiencing
something odd. We have a web site running on port 81 using JRun as the
servlet container and the built in JRun web server. We also have the same
site served through port 80 using IIS 5.0 as the web server and of course
JRun as the servlet container. Everything works beautifully -- except there
is one difference!
When I hit the JRun web server (port 81) form data is cached, apparently by
the browser, when I hit back and forward to return to the page. For
example, if I have a field called "name" and type in a value "Jeff", if I
hit back in my browser and then forward to return to the page, "Jeff"
appears in the the form field "name". Great! That's exactly what we want.
Now, I move over to the site served through IIS and it DOESN'T cache form
fields! If I add information to the field, hit back, and then forward, it's
blank. This is bad and I can't figure out how to fix it. Keep in mind, the
form is NOT getting posted. This is occurring when the user hits back and
forward to return to the original page.
This seemed to be browser independent -- it behaves this way on IE and
Netscape. The only thing that appears to be different is weather IIS or
JRun is doing the web serving. This lead me to believe, perhaps, there is a
HTTP header that controls client form field caching. Can't find anything
though. I've poked through the headers. At first I thought maybe the
Cache-Control header field might control this. On both the IIS and the JRun
web servers, this comes through as no-cache="set-cookie,set-cookie2". I
don't even know what that means, but they are the same, so it's unlikely any
headers are playing a role in weather or not the browser cached form fields.
I'm lost if anyone has any ideas! Thanks!
---
Jeff Stevens
System Engineer
Tradeout
(617) 283-3545
----------------------------------------------------------------------------
--
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe:
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe'
in the body.
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
