Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd


Do you have any idea what is the reason for this?

Manfred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 28.11.2022 um 10:43 schrieb Manfred Schwarz:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Manfred

Hi Manfred,
great, that you use Rivet.

I can imagine, that the data is mangled by the Apache web server or the receiving web browser.
What is the mime-type of the downloaded html response?
AFAIR, there is special download support in RIVET.

What it the Mime-Type of the response?
If there is a header like:
Content-Type: text/html; charset=utf-8
there might be some issues. https://tcl.apache.org/rivet/manual3.2/examples.html#file_download

It is also wise to ask on the rivet mailing list. It is moderated and
takes some time, but the experts are there.

Sorry, no more from my side,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Harald,

thank you for your response.

I am now one step further and have a working solution.
I noticed that there are many hexadecimal characters "0xC2A0" in the transmitted data.
In a discussion about Java I found the following hint: "Non-breaking space, 0x00A0 in UTF-16, is encoded as 0xC2A0 in UTF-8."

After that I modified the client as follows:

...

set token [http::geturl "http://<server-ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

set data [encoding convertfrom utf-8 $data]

while {[regexp "\\u000A$" $data]} {
set data [string range $data 0 end-1]
}

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd

...

This works and the files can be read again.

Do you have a better solution?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file
is text, when they should be indicating that it is a binary file.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file
is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Manfred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file
is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Hmm, binary mode was auto-enabled by the http module, so Tcl's http
should be downloading it correctly. If you save the data into a file
opened in binary mode, does a hash of that file match a hash of the
original on the server?

Can you also make updates to the rivet script? If yes, try this:

set fd [open my_file.xlsx {RDONLY BINARY}]
puts [read -nonewline $fd]
close $fd

Does that make any difference?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Montag, 28. November 2022 um 17:51:02 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file
is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet
Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Hmm, binary mode was auto-enabled by the http module, so Tcl's http
should be downloading it correctly. If you save the data into a file
opened in binary mode, does a hash of that file match a hash of the
original on the server?

Can you also make updates to the rivet script? If yes, try this:

set fd [open my_file.xlsx {RDONLY BINARY}]
puts [read -nonewline $fd]
close $fd

Does that make any difference?

The hash values are different (server: 5DE2182EF5455D69F8BDA31CD70F6D94 client: 02444C78C123647D4FE27A3ED0995C11).

The change in opening the output file doesn't make any difference

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 17:51:02 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file
is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet
Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Hmm, binary mode was auto-enabled by the http module, so Tcl's http
should be downloading it correctly. If you save the data into a file
opened in binary mode, does a hash of that file match a hash of the
original on the server?

Can you also make updates to the rivet script? If yes, try this:

set fd [open my_file.xlsx {RDONLY BINARY}]
puts [read -nonewline $fd]
close $fd

Does that make any difference?

The hash values are different (server: 5DE2182EF5455D69F8BDA31CD70F6D94 client: 02444C78C123647D4FE27A3ED0995C11).

The change in opening the output file doesn't make any difference

Hmm, just noticed this one, change this:

puts [read -nonewline $fd]

to this

puts -nonewline [read $fd]

You want all of the bytes read to go into the file, and you do not want
puts adding a newline of its own automatically.

The prior version is changing the file enough to make the hashes
differ.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Montag, 28. November 2022 um 18:56:27 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 17:51:02 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing >> >> here, we are very limited in being able to provide any troubleshooting >> >> help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file >> >> is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet
Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Hmm, binary mode was auto-enabled by the http module, so Tcl's http
should be downloading it correctly. If you save the data into a file
opened in binary mode, does a hash of that file match a hash of the
original on the server?

Can you also make updates to the rivet script? If yes, try this:

set fd [open my_file.xlsx {RDONLY BINARY}]
puts [read -nonewline $fd]
close $fd

Does that make any difference?

The hash values are different (server: 5DE2182EF5455D69F8BDA31CD70F6D94 client: 02444C78C123647D4FE27A3ED0995C11).

The change in opening the output file doesn't make any difference

Hmm, just noticed this one, change this:

puts [read -nonewline $fd]

to this

puts -nonewline [read $fd]

You want all of the bytes read to go into the file, and you do not want
puts adding a newline of its own automatically.

The prior version is changing the file enough to make the hashes
differ.

Hi Rich,

I have changed this. The hash is another, but not the same as the original.

Manfred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Manfred Schwarz <[email protected]>
| Today I tried this on the server, and it works:

| <?
| catch {unset data}

| set fd [open test.xlsx r]
| fconfigure $fd -translation binary
| set data [read $fd]
| close $fd

| ::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
| ::rivet::headers add Content-Length [string length $data]

| set origEncoding [encoding system]

| fconfigure stdout -encoding iso8859-1
| puts -nonewline "$data"
| fconfigure stdout -encoding $origEncoding
| ?>

I have a strong feeling against reading the data as binary and then
sending them as iso8859. It sounds to me like a data dependent bug
waiting to happen. As long as the data are all-ASCII, there should be
no problem, but as soon as you encounter non-ASCII... *possible boom*.

The data on disk have a specific encoding (which?), and so it seems best
to me to read them in that encoding.

Then indicate in the transfer-headers which encoding is used to send the
data, and send them in that encoding.

My EUR 0.01
R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Manfred Schwarz schrieb am Dienstag, 29. November 2022 um 09:00:18 UTC+1:

Rich schrieb am Montag, 28. November 2022 um 18:56:27 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 17:51:02 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Rich schrieb am Montag, 28. November 2022 um 16:27:58 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Hi All,

in my client-server application, the client needs to retrieve some binary files (e.g. Office files, images, etc.) from the server.
When the file is stored on the client, the corresponding application (e.g. Excel) cannot open the file because the file format is wrong.
The transferred file is larger than the original.
If I transfer the file directly (http::geturl http://<server_ip>/my_file.xlsx) or with WinScp, it is fine.

Client-Side:
...
package require http

set token [http::geturl "http://<server_ip>/get_my_file.rvt"]
set data [http::data $token]
http::cleanup $token

Without showing us the HTTP headers that the Rivet server is providing
here, we are very limited in being able to provide any troubleshooting
help.

set fd [open my_file.xlsx w]
fconfigure $fd -translation binary
puts -nonewline $fd $data
close $fd
...

Rivet-Script:
<?
::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

set fd [open my_file.xlsx r]
fconfigure $fd -translation binary
puts [read -nonewline $fd]
close $fd

Do you have any idea what is the reason for this?

Most commonly, it is because the http headers are indicating the file >> >> is text, when they should be indicating that it is a binary file.

Hi Rich,

thank you for your answer!

Following are some informations about the url on client side:

Connection = close
Content-Type = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date = Mon, 28 Nov 2022 1
GMT
Server = Apache/2.4.54 (Unix) OpenSSL/1.1.1l Rivet
Transfer-Encoding = chunked

% eval puts $$token\(status)
ok
% eval puts $$token\(charset)
iso8859-1
% eval puts $$token\(binary)
1

Hmm, binary mode was auto-enabled by the http module, so Tcl's http
should be downloading it correctly. If you save the data into a file
opened in binary mode, does a hash of that file match a hash of the
original on the server?

Can you also make updates to the rivet script? If yes, try this:

set fd [open my_file.xlsx {RDONLY BINARY}]
puts [read -nonewline $fd]
close $fd

Does that make any difference?

The hash values are different (server: 5DE2182EF5455D69F8BDA31CD70F6D94 client: 02444C78C123647D4FE27A3ED0995C11).

The change in opening the output file doesn't make any difference

Hmm, just noticed this one, change this:

puts [read -nonewline $fd]

to this

puts -nonewline [read $fd]

You want all of the bytes read to go into the file, and you do not want puts adding a newline of its own automatically.

The prior version is changing the file enough to make the hashes
differ.

Hi Rich,

I have changed this. The hash is another, but not the same as the original.

Manfred

I think I have the solution.

Today I tried this on the server, and it works:

<?
catch {unset data}

set fd [open test.xlsx r]
fconfigure $fd -translation binary
set data [read $fd]
close $fd

::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
::rivet::headers add Content-Length [string length $data]

set origEncoding [encoding system]

fconfigure stdout -encoding iso8859-1
puts -nonewline "$data"
fconfigure stdout -encoding $origEncoding


Then I found out that the new server uses the UTF-8 character set instead of the ISO-8859-1 like the old server.

So I just have to change the charset of the new server and it should work.

The simplest things are always thought of last. :-(

Thank you for your support and time.

Manfred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 29.11.2022 um 11:05 schrieb Ralf Fassel:

* Manfred Schwarz <[email protected]>
| Today I tried this on the server, and it works:

| <?
| catch {unset data}

| set fd [open test.xlsx r]
| fconfigure $fd -translation binary
| set data [read $fd]
| close $fd

| ::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
| ::rivet::headers add Content-Length [string length $data]

| set origEncoding [encoding system]

| fconfigure stdout -encoding iso8859-1
| puts -nonewline "$data"
| fconfigure stdout -encoding $origEncoding
| ?>

I have a strong feeling against reading the data as binary and then
sending them as iso8859. It sounds to me like a data dependent bug
waiting to happen. As long as the data are all-ASCII, there should be
no problem, but as soon as you encounter non-ASCII... *possible boom*.

The data on disk have a specific encoding (which?), and so it seems best
to me to read them in that encoding.

Then indicate in the transfer-headers which encoding is used to send the data, and send them in that encoding.

My EUR 0.01
R'

Ralf,
may I throw my 2 cents?
within TCL, iSO8859-1 and binary are synonyms with respect of the
encodings. This is due to the fact, that Unicode 0..255 is equal to 8859-1.
I learned that by examinating the encoding core and TCL embedding.

Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Manfred Schwarz <[email protected]> wrote:

Manfred Schwarz schrieb am Dienstag, 29. November 2022 um 09:00:18 UTC+1:
I think I have the solution.

Today I tried this on the server, and it works:

<?
catch {unset data}

set fd [open test.xlsx r]
fconfigure $fd -translation binary
set data [read $fd]
close $fd

::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
::rivet::headers add Content-Length [string length $data]

set origEncoding [encoding system]

fconfigure stdout -encoding iso8859-1
puts -nonewline "$data"
fconfigure stdout -encoding $origEncoding

Then I found out that the new server uses the UTF-8 character set
instead of the ISO-8859-1 like the old server.

So I just have to change the charset of the new server and it should work.

Except, if the file is really an xlsx file (as opposed to just being
named xlsx) then it is a zip file in disguise, and is really a binary
file, so transmitting it over a channel set to UTF-8 will corrupt the
binary data as Tcl translates the contents into UTF-8 encoding.

But, your 'fix' reminded me that I did not pay attention to the fact
that you were using rivet's stdout to send the file data, without first configuring stdout. What you'll want, for an xlsx file, is this:

<?
# this unset here is unnecessary if you do "set data" below, which
# will 'delete' any old 'data' variable contents anyway.
catch {unset data}

set fd [open test.xlsx r]
# adding -encoding binary makes sure Tcl does not modify the data
# in any way (this is why I prefer the {RDONLY BINARY} method for
# [open], then there is no need to fconfigure the channel
fconfigure $fd -translation binary -encoding binary
set data [read $fd]
close $fd

::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
::rivet::headers add Content-Length [string length $data]

# if you really want to reset things, you'll want to not do this
#set origEncoding [encoding system]

# and do this instead
set origConfig [fconfigure stdout]

fconfigure stdout -encoding binary -translation binary
puts -nonewline "$data"
fconfigure stdout -encoding [dict get $origConfig -encoding] -translation [dict get $origConfig -translation]
?>

But, do note that this above only works for files that really are meant
to be sent as binary data. Files that are meant to be sent as text
will be 'hit-or-miss' with the above pattern.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Dienstag, 29. November 2022 um 15:24:31 UTC+1:

Manfred Schwarz <[email protected]> wrote:

Manfred Schwarz schrieb am Dienstag, 29. November 2022 um 09:00:18 UTC+1:
I think I have the solution.

Today I tried this on the server, and it works:

<?
catch {unset data}

set fd [open test.xlsx r]
fconfigure $fd -translation binary
set data [read $fd]
close $fd

::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
::rivet::headers add Content-Length [string length $data]

set origEncoding [encoding system]

fconfigure stdout -encoding iso8859-1
puts -nonewline "$data"
fconfigure stdout -encoding $origEncoding

Then I found out that the new server uses the UTF-8 character set
instead of the ISO-8859-1 like the old server.

So I just have to change the charset of the new server and it should work.

Except, if the file is really an xlsx file (as opposed to just being
named xlsx) then it is a zip file in disguise, and is really a binary
file, so transmitting it over a channel set to UTF-8 will corrupt the
binary data as Tcl translates the contents into UTF-8 encoding.

But, your 'fix' reminded me that I did not pay attention to the fact
that you were using rivet's stdout to send the file data, without first configuring stdout. What you'll want, for an xlsx file, is this:

<?
# this unset here is unnecessary if you do "set data" below, which
# will 'delete' any old 'data' variable contents anyway.
catch {unset data}

set fd [open test.xlsx r]
# adding -encoding binary makes sure Tcl does not modify the data
# in any way (this is why I prefer the {RDONLY BINARY} method for
# [open], then there is no need to fconfigure the channel
fconfigure $fd -translation binary -encoding binary
set data [read $fd]
close $fd

::rivet::headers type "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
::rivet::headers add Content-Length [string length $data]
# if you really want to reset things, you'll want to not do this
#set origEncoding [encoding system]

# and do this instead
set origConfig [fconfigure stdout]

fconfigure stdout -encoding binary -translation binary
puts -nonewline "$data"
fconfigure stdout -encoding [dict get $origConfig -encoding] -translation [dict get $origConfig -translation]

But, do note that this above only works for files that really are meant
to be sent as binary data. Files that are meant to be sent as text
will be 'hit-or-miss' with the above pattern.

Thanks for your suggestion!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)