Changing content type

[Aaron Fude]

Hi,

I have a webpage delivers, let's say, a pdf document. The page is
password protected so itially it shows HTML, but when the user logs in
the page is reloaded with "window.location.reload(true)", but
IExplorer is not smart enough to realize that the content type has
changed and just spits out pdf onto the screen. How does one fix that?

Thanks!

Aaron

[Thomas 'PointedEars' Lahn]

Aaron Fude wrote:

I have a webpage delivers, let's say, a pdf document. The page is
password protected so itially it shows HTML, but when the user logs in
the page is reloaded with "window.location.reload(true)", but
IExplorer is not smart enough to realize that the content type has
changed and just spits out pdf onto the screen. How does one fix that?

Parse error. Please restate your request.

<http://www.jibbering.com/faq/#FAQ2_3>
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Aaron Fude]

On Jul 17, 2:42*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Aaron Fude wrote:

I have a webpage delivers, let's say, a pdf document. The page is
password protected so itially it shows HTML, but when the user logs in
the page is reloaded with "window.location.reload(true)", but
IExplorer is not smart enough to realize that the content type has
changed and just spits out pdf onto the screen. How does one fix that?

Parse error. *Please restate your request.

OK, fair enough. Let me try to approach this from this angle. Here's
pseudo code for my page on the server size.

if (user.notLoggedIn()) {
present.html.login.form();
when (user.submits.login.information)
window.location.reload(true);
}

else { // Now that the user has logged in...
output.a.pdf.file();
}

What happens in this scenario is that rather than invoking the acrobat
reader, the raw contents of the html file are displayed on the screen.

Does that make better sense?

Thanks!

[Joost Diepenmaat]

Aaron Fude <aa*******@gmail.comwrites:

else { // Now that the user has logged in...
output.a.pdf.file();
}

I suggest the problem is here. *How* do you output the pdf?

What happens in this scenario is that rather than invoking the acrobat
reader, the raw contents of the html file are displayed on the screen.

Does that make better sense?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Aaron Fude]

On Jul 17, 4:51*pm, Joost Diepenmaat <[e-mail]:

Aaron Fude <[e-mail]:

else { // Now that the user has logged in...
* output.a.pdf.file();
}

I suggest the problem is here. *How* do you output the pdf?

I programatically produce the pdf on the fly. The PDF is produce
correctly.

I should mention that when go inside the address bar and hit Enter to
refresh the page, everything works properly. It's just a question of
IExplorer not interpreting the content type correctly.

>

What happens in this scenario is that rather than invoking the acrobat
reader, the raw contents of the html file are displayed on the screen.

Does that make better sense?

--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

[Joost Diepenmaat]

Aaron Fude <aa*******@gmail.comwrites:

On Jul 17, 4:51Â*pm, Joost Diepenmaat <[e-mail]:

>Aaron Fude <[e-mail]:

else { // Now that the user has logged in...
Â* output.a.pdf.file();
}

I suggest the problem is here. *How* do you output the pdf?

I programatically produce the pdf on the fly. The PDF is produce
correctly.

Again, *how*? And are you sure you're giving the right content-type
header for the PDF?

I should mention that when go inside the address bar and hit Enter to
refresh the page, everything works properly. It's just a question of
IExplorer not interpreting the content type correctly.

If that's really the case, maybe you should use a different URL for
the PDF.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Aaron Fude]

On Jul 17, 5:26*pm, Joost Diepenmaat <[e-mail]:

Aaron Fude <[e-mail]:

On Jul 17, 4:51*pm, Joost Diepenmaat <[e-mail]:

Aaron Fude <[e-mail]:
else { // Now that the user has logged in...
* output.a.pdf.file();
}

I suggest the problem is here. *How* do you output the pdf?

I programatically produce the pdf on the fly. The PDF is produce
correctly.

Again, *how*? And are you sure you're giving the right content-type
header for the PDF?

Yes, I give it the right content-type as evidenced by what I said
below, but apparently IExplorer ignores it upon
window.location.reload(true)". Then on a hard refresh it reads it
properly. I'm not able to use a different URL for various reasons. I
just need to do something to force IExplorer to change the content
type.

>

I should mention that when go inside the address bar and hit Enter to
refresh the page, everything works properly. It's just a question of
IExplorer not interpreting the content type correctly.

If that's really the case, maybe you should use a different URL for
the PDF.

--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

[Joost Diepenmaat]

Aaron Fude <aa*******@gmail.comwrites:

On Jul 17, 5:26Â*pm, Joost Diepenmaat <[e-mail]:

>Aaron Fude <[e-mail]:

On Jul 17, 4:51Â*pm, Joost Diepenmaat <[e-mail]:
Aaron Fude <[e-mail]:
else { // Now that the user has logged in...
Â* output.a.pdf.file();
}

>I suggest the problem is here. *How* do you output the pdf?

I programatically produce the pdf on the fly. The PDF is produce
correctly.

Again, *how*? And are you sure you're giving the right content-type
header for the PDF?

Yes, I give it the right content-type as evidenced by what I said
below,

No, that's not evidence, that's a claim by you without any evidence.

but apparently IExplorer ignores it upon
window.location.reload(true)".

It might. I wouldn't be surprised if it did, but you haven't shown us
that it does.

Then on a hard refresh it reads it
properly. I'm not able to use a different URL for various reasons. I
just need to do something to force IExplorer to change the content
type.

And how do you suppose javascript figures into any of that?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Aaron Fude <aa*******@gmail.comwrites:

OK, fair enough. Let me try to approach this from this angle. Here's
pseudo code for my page on the server size.

if (user.notLoggedIn()) {
present.html.login.form();
when (user.submits.login.information)
window.location.reload(true);
}

else { // Now that the user has logged in...
output.a.pdf.file();
}

I am also deeply suspicious of any system that relies on client-side
javascript to do user athorization. Mostly because it's completely
unreliable.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Thomas 'PointedEars' Lahn]

Aaron Fude wrote:

Thomas 'PointedEars' Lahn wrote:

>Aaron Fude wrote:

>>I have a webpage delivers, let's say, a pdf document. The page is
password protected so itially it shows HTML, but when the user logs in
the page is reloaded with "window.location.reload(true)", but
IExplorer is not smart enough to realize that the content type has
changed and just spits out pdf onto the screen. How does one fix that?

Parse error. Please restate your request.

OK, fair enough. Let me try to approach this from this angle. Here's
pseudo code for my page on the server size.

Not a good idea, as noted in the FAQ. Even the URL for an uncommented test
case would have been more enlightening that this.

if (user.notLoggedIn()) {
present.html.login.form();
when (user.submits.login.information)
window.location.reload(true);
}

else { // Now that the user has logged in...
output.a.pdf.file();
}

What happens in this scenario is that rather than invoking the acrobat
reader, the raw contents of the html file are displayed on the screen.

Does that make better sense?

Unfortunately not. Suppose "size" was a typo for "side", hence this being
server-side J(ava)Script (.NET), then window.location.reload(true) would not
fit in as it is a client-side method. And if server-side scripting was not
meant with this, I wonder what client-side scripting would have to do with a
login, which should be secure. And even if made possible so in any way, why
would it be necessary to reload the entire document, discarding everything
done so far?

ISTM your approach is completely wrong, and you should read on how to built
a client-server Web application properly.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Bart Van der Donck]

Aaron Fude wrote:

I have a webpage delivers, let's say, a pdf document. The page is
password protected so itially it shows HTML, but when the user logs in
the page is reloaded with "window.location.reload(true)", but
IExplorer is not smart enough to realize that the content type has
changed and just spits out pdf onto the screen.

and

if (user.notLoggedIn()) {
present.html.login.form();
when (user.submits.login.information)
window.location.reload(true);
}
else {
output.a.pdf.file();
}

I'm afraid there is something wrong with your logic.
'output.a.pdf.file()' can not be used to load a PDF-document inside
the same web page, because the page was already served with content-
type text/html or the like. The only possibility is that
'output.a.pdf.file()' requests a new URI, like...

self.location.href = 'path/to/file.pdf';

....which initiates a fresh clean GET-request and response.

When you would use 'location.reload()', it refreshes exactly the same
URI (so, with the full HTML and the javascripts in it). By that time
you can't turn back the clock anymore to serve PDF on second thought.

Hope this helps,

--
Bart