blank line at beginning of downloaded file

[m. verkerk]

Hi everybody!

Hope someone can help me out with this!

I'm sending a file to a user with the following code:

header( "Content-Type: application/binary");
header( "Content-disposition: attachment; filename=$filen ame");
header( "Content-Transfer-Encoding: binary" );
passthru( "svnadmin dump ".$svn_repos_lo c."/".$name );

(the svnadmin dump command returns a mostly ascii file, but could also
contain some non-ascii parts)

Somehow the file that is saved on the recipients computer gets an
additional blank first line. Off course I can strip this somehow, but
I'm interested in an explanation of this behavior and I would like a
more appropriate solution!

Thanks & regards,
Marijn

[Peter Fox]

Following on from m. verkerk's message. . .

Hi everybody!

Hope someone can help me out with this!

I'm sending a file to a user with the following code:

header( "Content-Type: application/binary");
header( "Content-disposition: attachment; filename=$filen ame");
header( "Content-Transfer-Encoding: binary" );
passthru( "svnadmin dump ".$svn_repos_lo c."/".$name );

(the svnadmin dump command returns a mostly ascii file, but could also
contain some non-ascii parts)

Somehow the file that is saved on the recipients computer gets an
additional blank first line. Off course I can strip this somehow, but
I'm interested in an explanation of this behavior and I would like a
more appropriate solution!

CR <> CRLF <> LF problem?
The HTTP protocol (rfc2616) uses new lines /blank lines at the end of a
header and it hasa away of interpreting CR/LF etc.


--
PETER FOX Not the same since the poster business went to the wall
pe******@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Brion Vibber]

m. verkerk wrote:

Somehow the file that is saved on the recipients computer gets an
additional blank first line. Off course I can strip this somehow, but
I'm interested in an explanation of this behavior and I would like a
more appropriate solution!

Check for extra whitespace before the <? or after the ?> in your PHP
source files. Remember to check any include()s...

-- brion vibber (brion @ pobox.com)

[Malcolm Dew-Jones]

Brion Vibber (br***@pobox.co m) wrote:
: m. verkerk wrote:
: > Somehow the file that is saved on the recipients computer gets an
: > additional blank first line. Off course I can strip this somehow, but
: > I'm interested in an explanation of this behavior and I would like a
: > more appropriate solution!

: Check for extra whitespace before the <? or after the ?> in your PHP
: source files. Remember to check any include()s...

Note especially that it may be your editor inserting a final new line at
the very end of the php source file.

The > character in the final ?> must be the very last character in the
file.

On unix type "od -c file" to examine the bytes in the file. The last
bytes will be at the end (right?) so it doesn't matter if the file scrolls
by - you only need to see the last byte.

On windows, when all else fails, the lowly notepad can be used to find and
remove a trailing line break in a text file.

--

This space not for rent.

[Brion Vibber]

Malcolm Dew-Jones wrote:

Note especially that it may be your editor inserting a final new line at
the very end of the php source file.

The > character in the final ?> must be the very last character in the
file.

Actually, a single final newline after the ?> is ok. But if you have a
space *and* a final newline, or *two* final newlines, they will be output.

(At least this is the case on Unix; if you have Windows-style CRs in
there, who knows what dreadful things happen...)

-- brion vibber (brion @ pobox.com)

[Chung Leong]

"Malcolm Dew-Jones" <yf***@vtn1.vic toria.tc.ca> wrote in message
news:42******@n ews.victoria.tc .ca...

Brion Vibber (br***@pobox.co m) wrote:
: m. verkerk wrote:
: > Somehow the file that is saved on the recipients computer gets an
: > additional blank first line. Off course I can strip this somehow, but
: > I'm interested in an explanation of this behavior and I would like a
: > more appropriate solution!

: Check for extra whitespace before the <? or after the ?> in your PHP
: source files. Remember to check any include()s...

Note especially that it may be your editor inserting a final new line at
the very end of the php source file.

The > character in the final ?> must be the very last character in the
file.

Actually, PHP will swallow one linefeed right after ?> or </script>.

[Tim Roberts]

"m. verkerk" <m.*******@eras musmc.nl> wrote:

Hi everybody!

Hope someone can help me out with this!

I'm sending a file to a user with the following code:

header( "Content-Type: application/binary");

I doubt this is related to your problem, but the RFC1521-approved content
type for binary data is "applicatio n/octet-stream". "Applicatio n/binary"
is not defined, as far as I know.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[m. verkerk]

Thank you all for the help!

After closer examination, this white line seems to be caused by the
application framework I'm using (Prado).

thanks again!

Marijn

m. verkerk wrote:

Hi everybody!

Hope someone can help me out with this!

I'm sending a file to a user with the following code:

header( "Content-Type: application/binary");
header( "Content-disposition: attachment; filename=$filen ame");
header( "Content-Transfer-Encoding: binary" );
passthru( "svnadmin dump ".$svn_repos_lo c."/".$name );

(the svnadmin dump command returns a mostly ascii file, but could also
contain some non-ascii parts)

Somehow the file that is saved on the recipients computer gets an
additional blank first line. Off course I can strip this somehow, but
I'm interested in an explanation of this behavior and I would like a
more appropriate solution!

Thanks & regards,
Marijn

[John Dunlop]

Tim Roberts wrote:

but the RFC1521-approved content type for binary data is
"applicatio n/octet-stream".
Yes, arbitrary binary data.
"Applicatio n/binary" is not defined, as far as I know.

It isn't defined publicly; that is, it isn't registered
with the IANA. So the subtype should be prefixed with 'x-',
giving 'application/x-binary'.

But as you say, 'octet-stream' is the registered subtype.

--
Jock