.xsn file has fault after download with IE

[garyee]

Hello,

I know it is a pretty specific Problem... but it still is one...
When downloading a xsn file from a ce_download with IE the file can not be opened.

Steps to recreate:

1. take a contao installation (tested with a clean 3.5.3 install)
2. download a sample xsn (from here , unzip and Take Meeting_Agenda.xsn
3. install MS Infopath
4. allow xsn as down and upload in contao backend
5. put a ce_download element with the file up on the FE
6. Try download the file with Firefox via "open" (important)
   -> the File will be opened without a problem
7. Try the Same with IE (also just "open")
   -> the File will not be opened and InfoPath will throw an error

And just for fun
Try 5-7 with an ce_html and "hardcode" the a tag ... The file will open without a problem.

For those trying with local server be shure to add xsn with application/octet-stream in your config

[leofeyer]

be shure to add xsn with application/octet-stream in your config

This actually answers your question. It is a server configuration issue and not a Contao issue.

[garyee]

The Server is properly configured ... one can test that by hard-coding the file-link (with an ce_html)
The downloaded file still is not viable when downloaded from the ce_download element but is normal when downloaded from the ce_html. So the Problem seems to be with the download content element.

[leofeyer]

If it does work with Firefox but not with IE, I guess the problem cannot be the application. Can you please post the request and response headers? F12 will open the dev console in IE.

Anyone else on Windows having the same issue?

[garyee]

Anfrage IE

Anforderung GET /dokumente/formulare-a-z.html?file=files/inhalt/dokumente/formulare_a_bis_z/Arbeits-_und_Gesundheitsschutz/Baustellenbezogene_Gefaehrdungsbeurteilung.xsn HTTP/1.1
Accept      text/html, application/xhtml+xml, */*
Referer http://XXXXXXXX/dokumente/formulare-a-z.html
Accept-Language de-DE
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding  gzip, deflate
Host    XXXXXXXXXXXXXXXX
Connection  Keep-Alive
Cache-Control   no-cache
Cookie  PHPSESSID=ru9fghvnj3o4rl5

Antwort IE

Schlüssel  Wert
Antwort HTTP/1.1 200 OK
Cache-Control   must-revalidate, post-check=0, pre-check=0
Connection  close
Content-Disposition attachment; filename="Baustellenbezogene_Gefaehrdungsbeurteilung.xsn"
Content-Length  223734
Content-Transfer-Encoding   binary
Content-Type    application/octet-stream
Date    Thu, 05 Nov 2015 07:44:58 GMT
Expires 0
Pragma  public
Server  Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.6.3
Set-Cookie  BE_USER_AUTH=3fc734b8b376rtztrze4132f1750cecea81b50; expires=Wed, 04-Nov-2015 07:44:59 GMT; Max-Age=-86400; path=/; httponly
Set-Cookie  FE_USER_AUTH=869992rtzhjgfhcec09dab6nhfghf902a36cde4c322; expires=Wed, 04-Nov-2015 07:44:59 GMT; Max-Age=-86400; path=/; httponly
X-Powered-By    PHP/5.6.3

[leofeyer]

Try the Same with IE (also just "open") -> the File will not be opened and InfoPath will throw an error

What is the error message thrown?

[garyee]

The file is not the reason! When downloaded trough ce_html the file is opened without a problem.

[leofeyer]

Anyone else on Windows having the same issue?

[discordier]

Apparantly a proplem with InfoPath itself, see https://blogs.msdn.microsoft.com/infopath/2007/02/26/passing-data-into-a-form-input-parameters/

Quick summary:
Infopath handles the query string and tries to filter it's data with that.
Apparently Firefox downloads the file to Temp (or Downloads) prior handing it over to InfoPath whereas IE seems to hand over the URL to InfoPath and let that one Download the file then.
Of course InfoPath can not handle our query parameter file and hence produces total gibberish and fails miserably.

If above assumption is correct, there is nothing we can do about this.

@garyee could you try if you can reproduce it with an URL the like of:
http://example.com/files/path/to/file.xsn?file=produce/error.xsn
and post the resulting headers again?
Note the query string I appended, normally it will get ignored by apache but the browser knows about it.

[garyee]

I created a html content element and wrote the link to the ahref like you told me to and it worked, infopath opend the file.
The difference between the URL that you told me to insert and the URL which is passed by the download content element is:
url-of-file.file-extension?file=path-to-file (If I got you right) and
url-of-subpage-where-ce_download-is-on?file=path-to-file (ce_download)

And the second one is not working. (same result screenshot I posted a while ago)

So I think the problem is that Info path can't handle the file-argument and tries to download the in front of it.
But ... there is something that you could do about it. So I do not know why you put the file argument in the download elements URL, but a switch in the download elements BE would be nice, where one could choose if the html of the element is with the file argument or HTML5 download Attribute or something else, where the href of the a Tag is the actual path to the file.
Or replacing the version in use with some of the other ones. (But as I said, I do not know why you are doing it with the file argument, so ... yeah)

I could imagine that there are other types of files or programs which could run in the same problems.

[discordier]

The reason is, that you can restrict access to some directories within /files via .htaccess.
to allow to download files from these directories, Contao streams the file contents through php (hence the parameter, to know which file to stream).
If we would not do this, you could get an HTTP permission denied error instead of the file.

[leofeyer]

If above assumption is correct, there is nothing we can do about this.

So can I close the ticket then?

[garyee]

I don't know, a workaround is to create the download-link as an html-content-element. A fix could be to insert an option in the download-element config(BE) so that the user can switch the download between the "direct link" and the indirect (with files-argument). Up to you to decide :)

[discordier]

This would be indeed the only solution, a config flag to not passtrou the downloaded fila via php but supply the direct link instead.
However, I feel this could already be done by adjusting the template of the download content element and does not neccessarily need the flag in the download element.