Reading tcp ports in rebol line by line

The bug in rebol was two things: 1 A empty port in line mode doesn't produce none, it just waits for data. 2 An empty port always has a rebol newline character in it's buffer. I found this function for a server to be the best (so far) to read all of the headers of a http request from a client. Web: function [ Port [integer!] Root [file!] /Print-Request ][ Request Line Filename Error Disarmed ][ Listen: open/lines join tcp://: Port Stop: false while [not Stop] [ Request: make string! 1000 wait Listen Connection: first Listen if error? Error: try [ while [not empty? Line: Read-Connection] [ append Request rejoin [Line newline] ] Service Request Root :Read-Connection if Print-Request [print ["Request:" mold Request] none] ][ Disarmed: disarm Error either all [ Disarmed/type = 'access Disarmed/id = 'timeout ][ Stop: true ][ Error ] ] close Connection ] close Listen ] ] Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

It's a little different. Whether 'copy returns none or waits for data depends on whether you used the no-wait refinement for 'open. Without the refinement 'copy blocks, with it 'copy returns none if no data is available. This behavior applies to all /direct ports, not just ports in line mode. Regarding the newline character: in current versions there is the problem that in some circumstances after reading an incoming line that is terminated by crlf only the cr is read from the input buffer (a side effect of REBOL's automatic crlf conversion), not the nl, i.e. after the first line 'wait will return immediately (because of the nl), but 'copy still blocks, because no full new line is available. The current workaround is to explicitly tell REBOL what line terminator you want to use, by using the /with refinement, e.g. /wait "^/". The bug will be fixed in one of the next experimentals. -- Holger Kruse [holger--rebol--com]

I should warn you that opening the port as /string may not always be a good idea, since the browser could send you binary data with a POST method (for example), and you will want to send images as binary data. Of course you can use READ-IO and WRITE-IO to read/write binary data on a /string port, but shouldn't we avoid those functions if possible? YARWeS always used /binary ports to communicate with the browser. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

of

hmm, I remember the case when I used /binary port, then I looked at Sterling's proxy script and saw there is just 'open used without any refinement and also read/lines always worked for me ... not used ports for some time now, so maybe read/lines is buggy, as Holger explains ... Cheers, -pekr-

that in some circumstances after reading an incoming line that is terminated by crlf only the cr is read from the input buffer (a side effect of REBOL's automatic crlf conversion), not the nl, i.e. after the first line 'wait will return immediately (because of the nl), but 'copy still blocks, because no full new line is available.

you want to use, by using the /with refinement, e.g. /wait "^/". The bug will be fixed in one of the next experimentals. Thanks for the better explanation, Holger! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

of the headers of a http request from a client.

good idea, since the browser could send you binary data with a POST method (for example), and you will want to send images as binary data. Of course you can use READ-IO and WRITE-IO to read/write binary data on a /string port, but shouldn't we avoid those functions if possible?

That's a very good point. Thanks for pointing it out, Gabriele. I'll see if I can do it better, by using binary mode. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/