World: r3wp

I already did this for word syntax for R3, and the process led to 
some bug reports.

That's the second native bug I hit today...This morning while searching 
about an issue in Cheyenne's CGI handling (reported by PeterWood), 
I found out that the REBOL's CGI output in binary-mode is not working 
(it stays in string-mode, so corrupts binary data).


Is this the correct way to switch the CGI output to binary mode?: 
set-modes system/ports/output [binary: true]

I thought CGI required WRITE-IO for binary output.

In R2 at least.

I've tested both with INSERT and WRITE-IO, same result. But I've 
used CALL/OUTPUT on the test CGI script to simulate a call from a 
webserver.

Here's my test script: 
#!c:\dev\sdk\tools\rebol.exe  --cgi
REBOL []

print "Content-Type: application/octet-stream^/"
port: system/ports/output
set-modes port [binary: true]
insert port #{0D}

it's probably the PRINT that is corrupting

If you try to CALL/OUTPUT this script from 2.7.8, it will just freeze 
your REBOL session.

try using `prin rejoin [... crlf crlf]`

Testing that...

i vaguely remember that i had cgis using write-io to send binary 
output working

years ago :)

Was it on Windows?

definitely not

and the print/prin thing obviously won't help with CALL/output crashing 
or freezing

unless some line-ending recoding code in rebol is causing the crash 
:)

Then the error should show up less frequently, it would need #{0D0A} 
in the data to produce a corruption.

Your workaround doesn't work, same result, I'm getting #{0A} instead 
of #{0D}.

what if you set
system/ports/output/state/with: none

Same issue.

and with:
system/ports/output/state/with: "^/"

with: "^/" + write-io is another candidate :)

I was wondering if it could be related to a CALL issue, but my own 
CALL.r implementation in Cheyenne shows the same result. So I guess 
it's definitely an internal CGI handling issue.

Not any better...

Can't find any ticket related to this issue in RAMBO.

I think CGI  should set the line ending to crlf so PRINT  works right 
for the header, even on Linux.

http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg14312.html 


Tim said in 2002 in that post that "Is working intermittenly"...I 
wonder if this bug is not hiding there since the begginning (assuming 
that Tim was testing on Windows).

$ rebol --cgi --do "print 'foo" | hd
66 6f 6f 0a

Doesn't WRITE-IO work in binary mode even if the port is in text 
mode?

but even if it would, doc's original print would mix "^/" plus crlf

with: crlf => not working

WRITE-IO in text mode => not working

Ok, weird. I don't know if this is the case, but IMO the --cgi option 
should cause the output port to be in text mode and to convert ^/ 
to crlf, network standard. And then WRITE-IO should not do any conversions, 
and output in binary mode regardless of the text mode of the output 
port.

correction to the above: when actually running as cgi, `print rejoin 
[.. crlf]` seems to work fine

and write-io with 2.7.8 on linux actually running as cgi works fine 
as well

#!/usr/local/bin/rebol278 --cgi
REBOL []
print rejoin ["Content-type: application/octet-stream" crlf]
write-io system/ports/output data: #{610d620a63} length? data

`curl ... | hd` gives me `61 0d 62 0a 63` as desired

No conversion issues on linux: 


rebol --cgi --do "print 'foo p: system/ports/output set-modes p [binary: 
true] insert p #{0D0A}" | hd
00000000  66 6f 6f 0a 0d 0a

Launching the script with CALL on linux (using /Core 2.7.6) shows 
something interesting at the end :-))

>> s: "" call/output "rebol -c test.cgi" s
== 0
>> probe s                                
foo^/^/^M

Ok, no it's my mistake

Works flawlessly on linux.

I came across the issue as I was trying to run REBOL/Services under 
Cheyenne in GCI mode. I have found that 0x0D bytes get changed to 
0x0A, it doesn't matter what they are preceded or followed by.

I also found that 0x0D0D gets converted to a single 0x0A.

I suspect that the problem is more likely to be with 'call than REBOL 
in CGI mode as REBOL/Services  runs as a CGI under Xitami on Windows.

The problem does not occur on OS X.

I have run a test which seems to show that the problem lies with 
'call.

First I ran a small command line pgm:

Will post the results later ....

This is the console output from the command line pgm:

C:\REBOLServicesTest>cr
)haracter 13 is enclosed in the parentheses (


I then checked that the command line pgm could be successfully called 
with the following two lines of Ruby:

	puts %x{cr}
	print %x{cr}.dump

Which gave the following output:
C:\REBOLServicesTest>ruby call_test.rb
)haracter 13 is enclosed in the parentheses (
Character 13 is enclosed in the parentheses (\r)

I then called the command line pgm from a REBOL Console session:

>> call/console "cr"
Character 13 is enclosed in the parentheses (
)== 0
>> print to-binary {Character 13 is enclosed in the parentheses (
{    )}
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}
>> buffer: make string! 256
== ""
>> call/output "cr" buffer
== 0
>> probe buffer
Character 13 is enclosed in the parentheses (^/)
== "Character 13 is enclosed in the parentheses (^/)"
>> print to-binary buffer
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}


As you can see both call/console and call/output turned the 0x0D 
into a 0x0A.

I've added this to RAMBO.

I concur, it's a CALL issue and not a --cgi one. I did more tests 
with my own CALL/OUTPUT implementation and it doesn't show any newline 
alteration in the binary CGI output.

are there known bugs where DECOMPRESS works on certain data in one 
OS (OSX here), but not in another (Windows XP)?