«

I am trying to display a PDF in the users browser that is pulled from a
binary field in our database, and keep that PDF from caching on the
client computer. I can successfully pull the PDF and display it using
the following code:

Response.ContentType = "application/pdf"
Response.BinaryWrite objRS("Attachment")

where objRS("Attachment") is a reference to the binary field retrieved
from the database. However, I have tried adding virtually every header
known to have anything to do with caching, and I cannot seem to prevent
the PDF from caching in the client's browser. So then I tried to use
the adodb.stream object, as follows:

set objStream=server.createObject("ADODB.Stream")
objStream.Open
objStream.Type=1 'adTypeBinary
objStream.write objRS.fields("Attachment").value

Response.ContentType = "application/pdf"
Response.BinaryWrite objStream.Read()

This follows, more or less, several examples I've found on the web,
although most examples are reading a file into the stream, not a binary
field returned from a database. This code gives me the following
error:

Response object, ASP 0106 (0x80020005)
An unhandled data type was encountered.

I'm looking for a way to make the stream work, or any other suggestions
on how to display the pdf to the client without it caching in their
browser.

<> wrote in message
news: ups.com...
> I am trying to display a PDF in the users browser that is pulled from a
> binary field in our database, and keep that PDF from caching on the
> client computer. I can successfully pull the PDF and display it using
> the following code:
>
> Response.ContentType = "application/pdf"
> Response.BinaryWrite objRS("Attachment")
>
> where objRS("Attachment") is a reference to the binary field retrieved
> from the database. However, I have tried adding virtually every header
> known to have anything to do with caching, and I cannot seem to prevent
> the PDF from caching in the client's browser. So then I tried to use
> the adodb.stream object, as follows:
>
> set objStream=server.createObject("ADODB.Stream")
> objStream.Open
> objStream.Type=1 'adTypeBinary
> objStream.write objRS.fields("Attachment").value
>
> Response.ContentType = "application/pdf"
> Response.BinaryWrite objStream.Read()
>
> This follows, more or less, several examples I've found on the web,
> although most examples are reading a file into the stream, not a binary
> field returned from a database. This code gives me the following
> error:
>
> Response object, ASP 0106 (0x80020005)
> An unhandled data type was encountered.
>
> I'm looking for a way to make the stream work, or any other suggestions
> on how to display the pdf to the client without it caching in their
> browser.
>

You can't prevent the caching of the PDF on the client by modifying how the
PDF is streamed. At the end of the day the client sees the exact same
sequence of bytes.

What did you try in the headers. The following should prevent a cache from
re-using the content:-

Response.Expires = 0
Response.CacheControl = "private; max-age=0; no-cache"

You could also go with:-

Response.CacheControl = "private; max-age=0; no-store"

Also you could use a negative number for expires to make sure that a slow
clock on the client doesn't result in the content being cached. Browsers
using HTTP 1.1 will favor Cache-Control over Expiry date anyway.

How are you determining that a cache version is being re-used. The back
button on a browser for example may not be affected by any of these HTTP
headers.

I have tried the following headers:
response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
response.addheader "Cache-Control","no-store, no-cache,
must-revalidate"
response.addheader "Cache-Control","post-check=0, pre-check=0',
FALSE"
Response.AddHeader "Pragma", "no-cache"
Response.CacheControl="no-cache"
Response.expires=-1

I've tried various combinations of these as well. The way I am
determining whether or not it is cached is by clearing my cache,
loading the page, and looking at the cache - the PDF is there in the
cache still there. I'm not so concerned about the browser showing a
cached version instead of the latest version, I'm more concerned with
privacy. These PDF's contain sensitive information. I am worried
about someone viewing the PDF in their browser, then someone else
walking up to their computer and getting the PDF from their cache.
That's why I was wondering if by streaming the PDF if I could keep it
from saving an actual PDF file in their cache folder.

The interesting thing is that there are two pages involved - the first
is gerenated HTML that shows the list of available PDF's from the
database. I have successfully been able to prevent this page from
being cached with the following meta tags:
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="-1"

I have also added a cache-control:no-cache header using IIS on this
specific page (actually, all pages in this directory. The user clicks
one of the PDF links, and in a new window it opens the ASP page that is
application.pdf content type in a new browser window. Obviously I
can't put meta tags on this page, because it is not HTML - it's the
binary PDF, so I am stuck with HTTP headers. I will keep
experimenting, using your specific examples below and see what happens.


Anthony Jones wrote:
> You can't prevent the caching of the PDF on the client by modifying how the
> PDF is streamed. At the end of the day the client sees the exact same
> sequence of bytes.
>
> What did you try in the headers. The following should prevent a cache from
> re-using the content:-
>
> Response.Expires = 0
> Response.CacheControl = "private; max-age=0; no-cache"
>
> You could also go with:-
>
> Response.CacheControl = "private; max-age=0; no-store"
>
> Also you could use a negative number for expires to make sure that a slow
> clock on the client doesn't result in the content being cached. Browsers
> using HTTP 1.1 will favor Cache-Control over Expiry date anyway.
>
> How are you determining that a cache version is being re-used. The back
> button on a browser for example may not be affected by any of these HTTP
> headers.

One other thing that is strange - if I look at my cache using internet
explorer (tools -> options -> (general tab, settings button under
Temporary Internet Files section) -> View Files, then the PDF is not
there. The same thing is you navigate to C:\Documents and
Settings\username\Local Settings\Temporary Internet Files. However,
this is a special folder, and the actual files are stored in various
subdirectories in a content.ie5 subdirectory to the folder Temporary
Internet Files - windows just doesn't show it to you. So instead if
you navigate to \\computername\c$\documents and settings\username\local
settings\temporary internet files\content.ie5\ (windows no longer
treats it as a special folder) and search all files in this directory
and subdirectory, then you will find the PDF. Maybe I am just dealing
with the fact that this is just how internet explorer works, and there
is no way to prevent the actual file from existing on the client
computer?

By the way, I have the same problem with firefox - the cache is a
little more cryptic as there is no file extension, but nevertheless,
the file is still there, and is easily renamed and accessed.

wrote:
> I have tried the following headers:
> response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
> response.addheader "Cache-Control","no-store, no-cache,
> must-revalidate"
> response.addheader "Cache-Control","post-check=0, pre-check=0',
> FALSE"
> Response.AddHeader "Pragma", "no-cache"
> Response.CacheControl="no-cache"
> Response.expires=-1
>
> I've tried various combinations of these as well. The way I am
> determining whether or not it is cached is by clearing my cache,
> loading the page, and looking at the cache - the PDF is there in the
> cache still there. I'm not so concerned about the browser showing a
> cached version instead of the latest version, I'm more concerned with
> privacy. These PDF's contain sensitive information. I am worried
> about someone viewing the PDF in their browser, then someone else
> walking up to their computer and getting the PDF from their cache.

How will you prevent the user from hitting the "Save" button on their
browser/reader and saving a local copy of the file?

--
Mike Brind

Mike Brind wrote:
>> These PDF's contain sensitive information. I am worried about
>> someone viewing the PDF in their browser, then someone else
>> walking up to their computer and getting the PDF from their
>> cache.
>
> How will you prevent the user from hitting the "Save" button
> on their browser/reader and saving a local copy of the file?

Those are separate issues. Many of us work in environments where such
behavior is covered under regulatory guidelines, such as HIPAA. There can be
legitimate handling of sensitive data that involves saving files.

In any case, the OP is making an effort to safeguard that information when
the user is following his/her protection guidelines. Your question is
irrelevant.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Dave Anderson wrote:
> Mike Brind wrote:
> >> These PDF's contain sensitive information. I am worried about
> >> someone viewing the PDF in their browser, then someone else
> >> walking up to their computer and getting the PDF from their
> >> cache.
> >
> > How will you prevent the user from hitting the "Save" button
> > on their browser/reader and saving a local copy of the file?
>
> Those are separate issues. Many of us work in environments where such
> behavior is covered under regulatory guidelines, such as HIPAA. There can be
> legitimate handling of sensitive data that involves saving files.
>
> In any case, the OP is making an effort to safeguard that information when
> the user is following his/her protection guidelines. Your question is
> irrelevant.
>

Huh? Irrelevant to what? Of course I realise it's a separate issue to
the OP's problem, but it's one I am interested in knowing the answer
to. Hence I asked the question. That's what other people are allowed
to do here. And before you say it, yes, I also realise, strictly
speaking, it's OT for this group. But then so are all the html/css etc
questions that get answered.

Sod it... I withdraw the question.

--
Mike Brind

<> wrote in message
news: ups.com...
> I have tried the following headers:
> response.addheader "Expires","Mon, 26 Jul 1997 05:00:00 GMT"
> response.addheader "Cache-Control","no-store, no-cache,
> must-revalidate"
> response.addheader "Cache-Control","post-check=0, pre-check=0',
> FALSE"
> Response.AddHeader "Pragma", "no-cache"
> Response.CacheControl="no-cache"
> Response.expires=-1
>

Rather than mucking about with various headers lets just use the correct
headers for your requirement.

You want to attempt to stop the file from being cached at all. This could
be a problem for PDFs.

The correct code to acheive this is:-

Response.CacheControl = "private; no-store"

This informs all proxies between the origin server and the client not to
store a copy of the resource. It also tells the client that it should not
keep a copy of the resource. (no-cache actually means keep a copy if you
want but always check back with the origin server before using it)

The problem with this, at least with IE and PDFs, is that the implementation
doesn't appear to be able to handle rendering a PDF stream directly, it
needs to map the stream in to a file so despite the http headers saying
otherwise it is stored anyway. Why it isn't deleted after it has been
finished with I don't know it ought to be possible.



> I've tried various combinations of these as well. The way I am
> determining whether or not it is cached is by clearing my cache,
> loading the page, and looking at the cache - the PDF is there in the
> cache still there. I'm not so concerned about the browser showing a
> cached version instead of the latest version, I'm more concerned with
> privacy. These PDF's contain sensitive information. I am worried
> about someone viewing the PDF in their browser, then someone else
> walking up to their computer and getting the PDF from their cache.
> That's why I was wondering if by streaming the PDF if I could keep it
> from saving an actual PDF file in their cache folder.
>
> The interesting thing is that there are two pages involved - the first
> is gerenated HTML that shows the list of available PDF's from the
> database. I have successfully been able to prevent this page from
> being cached with the following meta tags:
> <meta http-equiv="Pragma" content="no-cache">
> <meta http-equiv="Cache-Control" content="no-cache">
> <meta http-equiv="Expires" content="-1"
>
> I have also added a cache-control:no-cache header using IIS on this
> specific page (actually, all pages in this directory. The user clicks
> one of the PDF links, and in a new window it opens the ASP page that is
> application.pdf content type in a new browser window. Obviously I
> can't put meta tags on this page, because it is not HTML - it's the
> binary PDF, so I am stuck with HTTP headers. I will keep
> experimenting, using your specific examples below and see what happens.
>
>
> Anthony Jones wrote:
> > You can't prevent the caching of the PDF on the client by modifying how
the
> > PDF is streamed. At the end of the day the client sees the exact same
> > sequence of bytes.
> >
> > What did you try in the headers. The following should prevent a cache
from
> > re-using the content:-
> >
> > Response.Expires = 0
> > Response.CacheControl = "private; max-age=0; no-cache"
> >
> > You could also go with:-
> >
> > Response.CacheControl = "private; max-age=0; no-store"
> >
> > Also you could use a negative number for expires to make sure that a
slow
> > clock on the client doesn't result in the content being cached.
Browsers
> > using HTTP 1.1 will favor Cache-Control over Expiry date anyway.
> >
> > How are you determining that a cache version is being re-used. The back
> > button on a browser for example may not be affected by any of these HTTP
> > headers.
>

That's basically the conclusion that I had come to - there is a
Microsoft support document (several, actually) on the problem of
downloading PDF's over an SSL, but I'm not using SSL - actually, in
this particular scenario, the client may or may not use SSL (inside
the company they don't - outside they do). Anyway, I will experiment
some more with the private; no-store heading - at least now I know the
correct header - thanks.

As to the question about how do you prevent a client from just saving
the PDF - you don't, and as has been stated already, that is
irrelevant. Of course someone can just save the PDF from their browser
- that's not the concern. the concern is someone ELSE pulling from a
users cache without their knowledge. Basically I am dealing with
people's pay stubs in PDF form, so if they want to save it, fine - they
can do whatever they want with it. I just don't want people pulling
OTHER employees pay stubs from their internet caches - at home, at
work, at the library, etc, etc.

> Rather than mucking about with various headers lets just use the correct
> headers for your requirement.
>
> You want to attempt to stop the file from being cached at all. This could
> be a problem for PDFs.
>
> The correct code to acheive this is:-
>
> Response.CacheControl = "private; no-store"
>
> This informs all proxies between the origin server and the client not to
> store a copy of the resource. It also tells the client that it should not
> keep a copy of the resource. (no-cache actually means keep a copy if you
> want but always check back with the origin server before using it)
>
> The problem with this, at least with IE and PDFs, is that the implementation
> doesn't appear to be able to handle rendering a PDF stream directly, it
> needs to map the stream in to a file so despite the http headers saying
> otherwise it is stored anyway. Why it isn't deleted after it has been
> finished with I don't know it ought to be possible.
>