xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Neilands <rneila...@pulsemining.com.au>
Subject Re: Large PDF's files fail to stream correctly
Date Tue, 08 Apr 2008 00:29:12 GMT
Just a thought but you could put it into a BLOB in a DB & apply your 
security to accessing that.
Alternatively encrypt the filesystem pdf for reading  & provide the 
password separately.

Regards,
Roland 


Woodhouse, Graeme wrote:
> Hi Daniel,
>
> Thanks for your help - as a bit of a test I tried the following two scenarios:
>
> I set the response size to Integer.MAX_VALUE. Which didn't work :(
>
> I also tried first saving the output to a file - waiting until the file was complete,
then streaming the file to the browser through the response. Which didn't work :(.
>
> Your right that I could temporarily link to the file I created and then delete the file
after but your right about the security access. Its not something that we could do as the
pdf's contain sensitive information + direct access to the server isn't really an option as
it bypasses the rest of the security we have in place.
>
> I don't suppose you or anyone else on the list know of any other way to get round this?
>
>
>
> Graeme Woodhouse
> Software Engineer
> ProQuest
>
> Direct-Line:              +44 (0) 1223 271 264
> Fax:                         +44 (0) 1223 215 513
>
>
> -----Original Message-----
> From: Daniel Appelt [mailto:daniel.appelt@gmail.com]
> Sent: 04 April 2008 18:43
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Large PDF's files fail to stream correctly
>
> Hi Graeme,
>
> in general, you do not know in advance how long the rendering with FOP
> will take. For large files it is not unlikely that the browser times
> out or finishes fetching the PDF file in an unfinished state.
> A possible pseudo-streaming solution could be to let FOP save the file
> on the server, and use a website with an AJAX script on the client
> side that regularly checks the state of the file. If file size isn't
> changing between two or more consecutive checks, it might be assumed
> that FOP has finished rendering the file and you could redirect the
> browser to the respective URL or show it as a link. Of course, this
> might still be problematic with regards to security...
>
> Cheers,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
> This e-mail is solely for the use of the intended recipient and may contain information
which is confidential or privileged. Any unauthorised use of its contents is prohibited. If
you have received this e-mail in error, please notify the sender via return e-mail and then
delete the original e-mail.
>
>   

This e-mail is solely for the use of the intended recipient and may contain information which
is confidential or privileged. Any unauthorised use of its contents is prohibited. If you
have received this e-mail in error, please notify the sender via return e-mail and then delete
the original e-mail.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message