Display PFD from binary in browser window (migration from cf10 to Lucee)

On CF10-11 I used this: to display my shipping (canada post) label
so I can print it.

A dump of the respond from Canada post API (cfhttp.FileContent) looks like
this on Lucee (but shorten quite a lot) (with the only difference being
that byte is binary on cf10 dump) :
Native Array (byte)Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On Lucee, the browser is telling me that “This PDF doc might not be
displayed correctly”… and it does not display at all. The browser offers
to try opening it with different viewers but the result is the same when I
do. They don’t read it as being a pdf file. Either Lucee can’t use pdf as
type for the tag cfcontent, or maybe conversion of raw fails. The wed
site: http://docs.lucee.org/reference/tags/content.html does not specify
any accepted type for cfcontet. So I’m left in the dark as to what is wrong.

Another post in Railo seems to be related to a somewhat similar situation (
https://groups.google.com/forum/#!searchin/railo/binary$20pdf/railo/6KQlOJo-Pe8/Dao4pVDBtVMJ)
, but I don’t understand the solution.

Dominique

Hi Dominique

It’s definitely possible in Lucee to output a PDF binary retrieved via
a http call. These two lines work for me with a simple test PDF:

http method="get" url="http://localhost/test.pdf"; content type="application/pdf" variable="#cfhttp.fileContent#";

If I dump the fileContent variable, I get the same as you: a Native
Array (byte), but that works fine when passed to cfcontent.

Can you post more of your code? And/or attach the PDF you’re working with?

Julian.On 1 October 2015 at 21:14, Dominique Dupuis <@Dominique_Dupuis> wrote:

On CF10-11 I used this: to display my shipping (canada post) label
so I can print it.

A dump of the respond from Canada post API (cfhttp.FileContent) looks like
this on Lucee (but shorten quite a lot) (with the only difference being that
byte is binary on cf10 dump) :
Native Array (byte)
Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On Lucee, the browser is telling me that “This PDF doc might not be
displayed correctly”… and it does not display at all. The browser offers
to try opening it with different viewers but the result is the same when I
do. They don’t read it as being a pdf file. Either Lucee can’t use pdf as
type for the tag cfcontent, or maybe conversion of raw fails. The wed site:
http://docs.lucee.org/reference/tags/content.html does not specify any
accepted type for cfcontet. So I’m left in the dark as to what is wrong.

Another post in Railo seems to be related to a somewhat similar situation
(https://groups.google.com/forum/#!searchin/railo/binary$20pdf/railo/6KQlOJo-Pe8/Dao4pVDBtVMJ)
, but I don’t understand the solution.

Dominique


See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your
ticket NOW - http://www.cfcamp.org/

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/84fecb71-54c6-4581-abd9-4de8e3a79fd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Julian,
You are correct, my code works when I feed it a pdf file located on the
server, using file=“C:…full path…” instead
of variable="#cfhttp.fileContent#".
The good news is that I now know for sure that Lucee can read these labels!
The bad news is that I’m back to square one on figuring out where and what
the problem is! Maybe something to do with the API call.
It is not obvious to post my code or the pdf results. (they may contain my
api credentials or customers info) But I will dig a bit further and try to
figure out what I can post here to help diagnose the problem.

Thank you
DominiqueOn Thursday, October 1, 2015 at 5:01:14 PM UTC-4, Julian Halliwell wrote:

Hi Dominique

It’s definitely possible in Lucee to output a PDF binary retrieved via
a http call. These two lines work for me with a simple test PDF:

http method="get" url="http://localhost/test.pdf"; content type="application/pdf" variable="#cfhttp.fileContent#";

If I dump the fileContent variable, I get the same as you: a Native
Array (byte), but that works fine when passed to cfcontent.

Can you post more of your code? And/or attach the PDF you’re working with?

Julian.

On 1 October 2015 at 21:14, Dominique Dupuis <domini...@gmail.com <javascript:>> wrote:

On CF10-11 I used this: to display my shipping (canada post)
label
so I can print it.

A dump of the respond from Canada post API (cfhttp.FileContent) looks
like
this on Lucee (but shorten quite a lot) (with the only difference being
that
byte is binary on cf10 dump) :
Native Array (byte)
Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On Lucee, the browser is telling me that “This PDF doc might not be
displayed correctly”… and it does not display at all. The browser
offers
to try opening it with different viewers but the result is the same when
I
do. They don’t read it as being a pdf file. Either Lucee can’t use pdf
as
type for the tag cfcontent, or maybe conversion of raw fails. The wed
site:
http://docs.lucee.org/reference/tags/content.html does not specify any
accepted type for cfcontet. So I’m left in the dark as to what is wrong.

Another post in Railo seems to be related to a somewhat similar
situation
(
https://groups.google.com/forum/#!searchin/railo/binary$20pdf/railo/6KQlOJo-Pe8/Dao4pVDBtVMJ)

, but I don’t understand the solution.

Dominique


See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get
your
ticket NOW - http://www.cfcamp.org/

You received this message because you are subscribed to the Google
Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com
<javascript:>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/84fecb71-54c6-4581-abd9-4de8e3a79fd9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Julian,
I have successfully loaded a pdf from file like you said. This tells me it
as to do with the API call itself.
After some more debug sessions, I turned on Network inspector in my browser
and compare the request header (from cf11 vs Lucee) and I found some
mismatch.

When using the followign code (used to retreive tracking info on a
shippment)






Lucee seems to had things to my header, for example:
Accept-Language in CF11 = “en-US” becomes in Lucee “en-US,en;q=0.5”
the same goes for Accept:
CF11: text/html, application/xhtml+xml, /
Lucee: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

The first thing wrong of course it that Lucee adds some q= stuff compared
to CF. But also, both fields do not match what I have in
the cfhttpparam value. This probably means I did not figure out how to get
the header of this particular code… and that I’ve pasted here only the
header for the page in general, not the api cfhttp call. Either way,
my api call will not work if Lucee adds stuff to my headers.

So where do I go from here?
Thank youOn Thursday, October 1, 2015 at 4:14:49 PM UTC-4, Dominique Dupuis wrote:

On CF10-11 I used this: to display my shipping (canada post) label
so I can print it.

A dump of the respond from Canada post API (cfhttp.FileContent) looks like
this on Lucee (but shorten quite a lot) (with the only difference being
that byte is binary on cf10 dump) :
Native Array (byte)Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On Lucee, the browser is telling me that “This PDF doc might not be
displayed correctly”… and it does not display at all. The browser offers
to try opening it with different viewers but the result is the same when I
do. They don’t read it as being a pdf file. Either Lucee can’t use pdf as
type for the tag cfcontent, or maybe conversion of raw fails. The wed
site: http://docs.lucee.org/reference/tags/content.html does not specify
any accepted type for cfcontet. So I’m left in the dark as to what is wrong.

Another post in Railo seems to be related to a somewhat similar situation (
https://groups.google.com/forum/#!searchin/railo/binary$20pdf/railo/6KQlOJo-Pe8/Dao4pVDBtVMJ)
, but I don’t understand the solution.

Dominique

Hi Dominique

I’m not sure if the Accept/language headers are a factor since ACF is also
ignoring your specified values.

However the fact that you are using Basic Authentication over SSL may be
cause of the problem. I’ve found that Railo and Lucee both fail to generate
the authorization header containing the username and password when using
SSL/port 443. See these 2 tickets:

https://luceeserver.atlassian.net/browse/LDEV-95
https://issues.jboss.org/browse/RAILO-3315

I was able to work around this by adding the username/password manually
using cfhttpparam. So in your case it would be:

Cheers
Julian.On 15 October 2015 at 23:42, Dominique Dupuis <@Dominique_Dupuis> wrote:

Julian,
I have successfully loaded a pdf from file like you said. This tells me it
as to do with the API call itself.
After some more debug sessions, I turned on Network inspector in my
browser and compare the request header (from cf11 vs Lucee) and I found
some mismatch.

When using the followign code (used to retreive tracking info on a
shippment)






Lucee seems to had things to my header, for example:
Accept-Language in CF11 = “en-US” becomes in Lucee “en-US,en;q=0.5”
the same goes for Accept:
CF11: text/html, application/xhtml+xml, /
Lucee: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

The first thing wrong of course it that Lucee adds some q= stuff compared
to CF. But also, both fields do not match what I have in
the cfhttpparam value. This probably means I did not figure out how to get
the header of this particular code… and that I’ve pasted here only the
header for the page in general, not the api cfhttp call. Either way,
my api call will not work if Lucee adds stuff to my headers.

So where do I go from here?

Glad to help, Dominique.

Lucee isn’t ignoring all your cfhttpparam values, just the
Accept/Accept-language ones it seems. But so apparently does ACF for
those headers. The Authorization header is definitely not ignored
though, but Lucee should be generating it automatically when you
specify a username and password in the main cfhttp attributes. That’s
a bug. As it’s affected you could I encourage you to vote for it to be
fixed?

https://luceeserver.atlassian.net/browse/LDEV-95

Thanks.
Julian.On 16 October 2015 at 18:56, Dominique Dupuis <@Dominique_Dupuis> wrote:

Hi Julian, You figured it out! I changed all my headers and it all works
fine now. I don’t quite understand why it works since like you said, it
seems to be ignoring my other values specified in the other cfhttpparam tags
, but it works, so I’m moving on to the next migration bug. Thank you for
your help!

Hi Julian, You figured it out! I changed all my headers and it all works
fine now. I don’t quite understand why it works since like you said, it
seems to be ignoring my other values specified in the other cfhttpparam
tags , but it works, so I’m moving on to the next migration bug. Thank you
for your help!
DominiqueOn Friday, October 16, 2015 at 4:00:06 AM UTC-4, Julian Halliwell wrote:

Hi Dominique

I’m not sure if the Accept/language headers are a factor since ACF is also
ignoring your specified values.

However the fact that you are using Basic Authentication over SSL may be
cause of the problem. I’ve found that Railo and Lucee both fail to generate
the authorization header containing the username and password when using
SSL/port 443. See these 2 tickets:

https://luceeserver.atlassian.net/browse/LDEV-95
https://issues.jboss.org/browse/RAILO-3315

I was able to work around this by adding the username/password manually
using cfhttpparam. So in your case it would be:

Cheers
Julian.

On 15 October 2015 at 23:42, Dominique Dupuis <domini...@gmail.com <javascript:>> wrote:

Julian,
I have successfully loaded a pdf from file like you said. This tells me
it as to do with the API call itself.
After some more debug sessions, I turned on Network inspector in my
browser and compare the request header (from cf11 vs Lucee) and I found
some mismatch.

When using the followign code (used to retreive tracking info on a
shippment)






Lucee seems to had things to my header, for example:
Accept-Language in CF11 = “en-US” becomes in Lucee “en-US,en;q=0.5”
the same goes for Accept:
CF11: text/html, application/xhtml+xml, /
Lucee: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

The first thing wrong of course it that Lucee adds some q= stuff compared
to CF. But also, both fields do not match what I have in
the cfhttpparam value. This probably means I did not figure out how to get
the header of this particular code… and that I’ve pasted here only the
header for the page in general, not the api cfhttp call. Either way,
my api call will not work if Lucee adds stuff to my headers.

So where do I go from here?

Right, got it. and I voted. Tks again, DominiqueOn Friday, October 16, 2015 at 2:58:33 PM UTC-4, Julian Halliwell wrote:

Glad to help, Dominique.

Lucee isn’t ignoring all your cfhttpparam values, just the
Accept/Accept-language ones it seems. But so apparently does ACF for
those headers. The Authorization header is definitely not ignored
though, but Lucee should be generating it automatically when you
specify a username and password in the main cfhttp attributes. That’s
a bug. As it’s affected you could I encourage you to vote for it to be
fixed?

https://luceeserver.atlassian.net/browse/LDEV-95

Thanks.
Julian.

On 16 October 2015 at 18:56, Dominique Dupuis <domini...@gmail.com <javascript:>> wrote:

Hi Julian, You figured it out! I changed all my headers and it all
works
fine now. I don’t quite understand why it works since like you said, it
seems to be ignoring my other values specified in the other cfhttpparam
tags
, but it works, so I’m moving on to the next migration bug. Thank you
for
your help!

Actually on reflection, I suspect neither Lucee nor ACF are ignoring
your Accept/language headers. You said you used the Network inspector
in your browser to look at them, but that will only show you details
of the request from your browser to Lucee, not Lucee’s request to the
3rd party provider via cfhttp. To check those, you would need to dump
the cfhttp result struct. I would expect that to match exactly what
you specify in your cfhttpparams.

Thanks for voting on the SSL/authentication bug.

Julian.On 18 October 2015 at 20:59, Dominique Dupuis <@Dominique_Dupuis> wrote:

Right, got it. and I voted. Tks again, Dominique

On Friday, October 16, 2015 at 2:58:33 PM UTC-4, Julian Halliwell wrote:

Lucee isn’t ignoring all your cfhttpparam values, just the
Accept/Accept-language ones it seems. But so apparently does ACF for
those headers. The Authorization header is definitely not ignored
though, but Lucee should be generating it automatically when you
specify a username and password in the main cfhttp attributes. That’s
a bug. As it’s affected you could I encourage you to vote for it to be
fixed?

https://luceeserver.atlassian.net/browse/LDEV-95

On 16 October 2015 at 18:56, Dominique Dupuis domini...@gmail.com wrote:

Hi Julian, You figured it out! I changed all my headers and it all
works
fine now. I don’t quite understand why it works since like you said, it
seems to be ignoring my other values specified in the other cfhttpparam
tags
, but it works, so I’m moving on to the next migration bug. Thank you
for
your help!

Hi, First, let me say that my shipping module codes do work. I did need to
modify a few more things that cf10 would just let slip by.

But what you wrote made sense and I wanted to test that. And again I could
be doing something wrong but when I run:





In that dump, I can find none of my 3 cfhttpparam headers, yet the api
accepts the call and does return a proper filecontent.
Here is a copy of my dump: (let me know what you think. Tks)

Test resultsStruct
Entries: 12charsetstringUTF-8cookiesQuery
Execution Time: 0 ms
Record Count: 1
Cached: No
Lazy: No
namevaluepathdomainexpiressecurehttpOnly1CPO_SSID_P30W1
ffffffff09ed4a7b45525d5f4f58455e445a4a4243a5/falsetruevar.cookieserrordetail
stringfilecontentstring<?xml version="1.0" encoding="UTF-8"?>< manifests
xmlns=“http://www.canadapost.ca/ws/manifest”>headerstringHTTP/1.1
200 OK Server: Web Server Date: Wed, 04 Nov 2015 19:22:28 GMT
X-backside-transport: OK OK,OK OK Content-type:
application/vnd.cpc.manifest-v2+xml; charset=UTF-8 Set-cookie:
CPO_SSID_P30W1=ffffffff09ed4a7b45525d5f4f58455e445a4a4243a5;path=/;httponly
X-global-transaction-id: 1233540993 Svn-build-number:
ShippingTools.buildLevel.20151024.DP10_2015-B6912.6912 X-client-ip:
10.229.109.82 Transfer-encoding: chunkedhttp_versionstringHTTP/1.1mimetype
stringapplication/vnd.cpc.manifest-v2+xmlresponseheaderStruct
Entries: 11Content-typestringapplication/vnd.cpc.manifest-v2+xml;
charset=UTF-8DatestringWed, 04 Nov 2015 19:22:28 GMTexplanationstringOK
ServerstringWeb Serverset-cookieArray1string
CPO_SSID_P30W1=ffffffff09ed4a7b45525d5f4f58455e445a4a4243a5;path=/;httponly
status_codenumber200Svn-build-numberstring
ShippingTools.buildLevel.20151024.DP10_2015-B6912.6912Transfer-encoding
stringchunkedX-backside-transportstringOK OK,OK OKX-client-ipstring
10.229.109.82X-global-transaction-idstring1233540993status_codenumber200
status_textstringOKstatuscodestring200 OKtextbooleantrueOn Sunday, October 18, 2015 at 4:42:48 PM UTC-4, Julian Halliwell wrote:

Actually on reflection, I suspect neither Lucee nor ACF are ignoring
your Accept/language headers. You said you used the Network inspector
in your browser to look at them, but that will only show you details
of the request from your browser to Lucee, not Lucee’s request to the
3rd party provider via cfhttp. To check those, you would need to dump
the cfhttp result struct. I would expect that to match exactly what
you specify in your cfhttpparams.

Thanks for voting on the SSL/authentication bug.

Julian.

On 18 October 2015 at 20:59, Dominique Dupuis <domini...@gmail.com <javascript:>> wrote:

Right, got it. and I voted. Tks again, Dominique

On Friday, October 16, 2015 at 2:58:33 PM UTC-4, Julian Halliwell wrote:

Lucee isn’t ignoring all your cfhttpparam values, just the
Accept/Accept-language ones it seems. But so apparently does ACF for
those headers. The Authorization header is definitely not ignored
though, but Lucee should be generating it automatically when you
specify a username and password in the main cfhttp attributes. That’s
a bug. As it’s affected you could I encourage you to vote for it to be
fixed?

https://luceeserver.atlassian.net/browse/LDEV-95

On 16 October 2015 at 18:56, Dominique Dupuis domini...@gmail.com wrote:

Hi Julian, You figured it out! I changed all my headers and it all
works
fine now. I don’t quite understand why it works since like you said,
it

seems to be ignoring my other values specified in the other
cfhttpparam

tags
, but it works, so I’m moving on to the next migration bug. Thank
you

for
your help!

Hi Dominique

Sorry I was wrong to expect the headers sent by cfhttp to be in the
dumped result. That only gives the headers sent back via the http call
(being the result of the call).

But I’ve set up a test in which I make a cfhttp call with your
httpparams over SSL to a remote Lucee endpoint that I control. This
then simply outputs the HTTP data it receives using . I then dump the result of the call and
the remote dump captured in the fileContent clearly shows all the
headers having been sent.

There’s probably an easier way of checking the outgoing headers of
cfhttp, but that’s how I identified this bug with Railo/Lucee in the
first place.

Cheers
Julian.On 4 November 2015 at 19:28, Dominique Dupuis <@Dominique_Dupuis> wrote:

Hi, First, let me say that my shipping module codes do work. I did need to modify a few more things that cf10 would just let slip by.

But what you wrote made sense and I wanted to test that. And again I could be doing something wrong but when I run:





In that dump, I can find none of my 3 cfhttpparam headers, yet the api accepts the call and does return a proper filecontent.
Here is a copy of my dump: (let me know what you think. Tks)