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

[Dominique Dupuis]

On CF10-11 I used this: <cfcontent type="application/pdf" variable="#cfhttp.FileContent#"> 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 Encoded	PD94(..........................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

[Julian Halliwell]

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:

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

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> wrote:
> On CF10-11 I used this: <cfcontent type="application/pdf"
> variable="#cfhttp.FileContent#"> 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.
> To post to this group, send email to lu...@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.

[Dominique Dupuis]

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

Dominique

[Dominique Dupuis]

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) 

<cfhttp url="#application.cw.CanPostUrl#/vis/track/pin/#arguments.pin#/#arguments.ResultType#" method="get" port="443"  username="#application.cw.CanPostusername#" password="#application.cw.CanPostPassword#"  resolveurl="no" >

                <cfhttpparam name="accept" type="header" value="application/vnd.cpc.manifest-v2+xml">

                <cfhttpparam name="Content-Type" type="header" value="application/vnd.cpc.manifest-v2+xml">

                <cfhttpparam name="Authorization" type="header" value="Basic">

                <cfhttpparam name="Accept-language" type="header" value="en-CA">

            </cfhttp> 

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 you

[Julian Halliwell]

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:

<cfhttpparam type="header" name="Authorization" value="Basic #ToBase64( application.cw.CanPostusername & ':' & application.cw.CanPostPassword )#">

Cheers

Julian.

[Dominique Dupuis]

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!
Dominique

[Julian Halliwell]

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.

[Dominique Dupuis]

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

[Julian Halliwell]

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> 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
>>
>>

[Dominique Dupuis]

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:

<cfhttp url="#application.cw.CanPostUrl#/rs/000_______/000______/manifest?start=#startdate#&end=#enddate#" method="get" port="443" result="MyResults"  >

                <cfhttpparam name="accept" type="header" value="application/vnd.cpc.manifest-v2+xml">

                <cfhttpparam type="header" name="Authorization" value="Basic #ToBase64(application.cw.CanPostusername & ':' & application.cw.CanPostPassword)#">

                <cfhttpparam name="accept-language" type="header" value="fr-CA">

</cfhttp>

<cfdump var="#MyResults#" label="Test results"><cfabort>

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 results

Struct Entries: 12 charset string UTF-8 cookies Query Execution Time: 0 ms Record Count: 1 Cached: No Lazy: No   name value path domain expires secure httpOnly 1 CPO_SSID_P30W1 ffffffff09ed4a7b45525d5f4f58455e445a4a4243a5 / false true var.cookies errordetail string filecontent string <?xml version="1.0" encoding="UTF-8"?>< manifests xmlns="http://www.canadapost.ca/ws/manifest"><link rel="manifest" href="https://soa-gw.canadapost.ca:443/rs/0003421597/0003421597/manifest/576851446582113474" media-type="application/vnd.cpc.manifest-v2+xml"/></manifests> header string HTTP/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: chunked http_version string HTTP/1.1 mimetype string application/vnd.cpc.manifest-v2+xml responseheader Struct Entries: 11 Content-type string application/vnd.cpc.manifest-v2+xml; charset=UTF-8 Date string Wed, 04 Nov 2015 19:22:28 GMT explanation string OK Server string Web Server set-cookie Array 1 string CPO_SSID_P30W1=ffffffff09ed4a7b45525d5f4f58455e445a4a4243a5;path=/;httponly status_code number 200 Svn-build-number string ShippingTools.buildLevel.20151024.DP10_2015-B6912.6912 Transfer-encoding string chunked X-backside-transport string OK OK,OK OK X-client-ip string 10.229.109.82 X-global-transaction-id string 1233540993 status_code number 200 status_text string OK statuscode string 200 OK text boolean true

[Julian Halliwell]

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 <cfdump
var="#getHTTPRequestData()#">. 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.