D
davidmichaelkarr
I'm seeing an odd issue in my application that might be caused by how
IE caches pages, and what URL it stores for the cached page.
I have a servlet application that takes a request parameter
representing the "name" of a form (not the path to it). Our intranet
proxies pass an HTTP header that specifies the userid of the user. The
servlet reads that header, then retrieves data from LDAP, and then
redirects to a new URL, specifying the full path to the form, and
passing several request parameters containing LDAP data. The
Javascript in the form reads the request parameters and autofills some
fields. If it doesn't see those request parameters, it presents an
error dialog. This has been working fine, up to a day or so ago when
we upgraded everyone to Acrobat Reader 7.0, and also installed a bunch
of IE security fixes.
I'm running a test case where I bring up a new instance of IE and paste
in the initial URL to the form (that just has the form name). The
first time this works fine. I then paste the original URL back into
the URL field and press enter. This time, I get the error dialog that
said it couldn't find the parameters.
What I realized, after adding some alerts to my javascript, and
monitoring the access log on my servlet engine, is that when I do the
first request, everything looks normal. On the second request, what I
see is that IE doesn't submit to the servlet at all, it just serves up
the cached PDF. However, the URL variable that the javascript in the
form sees is for the ORIGINAL url, not the redirect url, that really
downloaded the form. As a result, my form javascript fails, because it
can't find the parameters. Even stranger, when I look in the URL field
in the browser, the original URL is not there, the redirect URL is
there. That's what the form should have received, but it received the
original URL instead.
The only significant changes that I know about are Acrobat Reader 7.0
and the monthly Windows patches install.
IE caches pages, and what URL it stores for the cached page.
I have a servlet application that takes a request parameter
representing the "name" of a form (not the path to it). Our intranet
proxies pass an HTTP header that specifies the userid of the user. The
servlet reads that header, then retrieves data from LDAP, and then
redirects to a new URL, specifying the full path to the form, and
passing several request parameters containing LDAP data. The
Javascript in the form reads the request parameters and autofills some
fields. If it doesn't see those request parameters, it presents an
error dialog. This has been working fine, up to a day or so ago when
we upgraded everyone to Acrobat Reader 7.0, and also installed a bunch
of IE security fixes.
I'm running a test case where I bring up a new instance of IE and paste
in the initial URL to the form (that just has the form name). The
first time this works fine. I then paste the original URL back into
the URL field and press enter. This time, I get the error dialog that
said it couldn't find the parameters.
What I realized, after adding some alerts to my javascript, and
monitoring the access log on my servlet engine, is that when I do the
first request, everything looks normal. On the second request, what I
see is that IE doesn't submit to the servlet at all, it just serves up
the cached PDF. However, the URL variable that the javascript in the
form sees is for the ORIGINAL url, not the redirect url, that really
downloaded the form. As a result, my form javascript fails, because it
can't find the parameters. Even stranger, when I look in the URL field
in the browser, the original URL is not there, the redirect URL is
there. That's what the form should have received, but it received the
original URL instead.
The only significant changes that I know about are Acrobat Reader 7.0
and the monthly Windows patches install.