Yeah, our situation is clearly different. All of our forms work fine (we
use GET action not POST). It's just when the user enters data, hits back
and then forward, the data is lost under IIS and JRun. Under the JRun web
server it works fine. These are the actual browser back and forward
buttons, not any buttons on the pages so there is no GET or POST made. I
still think it has to be something related to the cach-control: no-cache
header but this header shows up on both IIS/JRun and JRun/JRun so I dunno.
Yeah, I have opened a support case with Allaire. The guy was pretty
condecending and had the nerve to ask me if I was even familiar with web
development.
The funny thing is, it works fine under IIS alone, and JRun with the JRun
web server. It's only failing when we use IIS and JRun. Go figure. We
have actually nailed it down to working incorrectly under IIS and JRun when
we push cookies to clients. Go figure! Works fine under JRun's web server
when we push cookes -- as well as IIS when we push cookies with ASP -- just
not IIS and JRun pushing cookies. It's clearly a JRun support issue -- yet
they ignore it. It's either some congfiguration I am missing or a bug (yet
another) in JRun. We'll see!
-Jeff
> -----Original Message-----
> From: Brian Zimmer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 12, 2000 4:25 PM
> To: '[EMAIL PROTECTED]'
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Form Caching Question
>
>
> 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.
