AltME groups: search

My, my, my...


I think some features in SVG, are too much work to implement with 
Rebol.

1/ The "objectBoundingBox" units.

Which means, coordinates and lengths are ratio or percentages. 

And they are converted to real units depending of the bounding box 
of the shape on which they apply.
It's easy to calculate when the shapes are boxes or vectors. 

But when it comes with arcs or curves, it becomes a pain in the ass.


It's not a real problem because Inkscape for example has an option 
(simplify shapes) to convert all the ratio units in real units (ie. 
pixel units).

So, I don't see the interest to rewrite DRAW from scratch with Rebol.

(because it's what it means, to be able to calculate all the bounding 
box)

2/ Outlines with gradients


Those fullishs can specify a gradient for the pen attribute (which 
draw the outlines).
Rebol can only have a gradient to fill a shape.
It can be simulated by drawing the related shape 2 times.
1 time with the pen gradient.

A second time with the fill-pen attribute (which can be a gradient 
too).

But the second time the shape must be, at first, downsized of the 
line width.

To do so, it means that we need to know the center of the Bounding 
box of the shape.
So, same problem than 1/


3/ The fill-pen attribute (gradient or color) never apply on the 
outline of the shape, event if the outline has no color but actually 
has a width.

It allows SVG for example, to have transparent outlines.
We can't do that with Rebol. 

Because the fill-pen attributes (or the gradient) fills all the shape 
at first.
And then the outline is drawed over.

If we don't provide a pen color, or we provide a transparent color, 
we see the fill-pen content instead, at the place of the outline.


Perhaps, that can be modified in Draw. A nice request but not a so 
considerable feature to my mind.

(And it can be impossible to implement this in Draw, if AGG doesn't 
support it at first).

Will you  transfer the request to Carl ?

Is it multicategory? I mean - all draw related stuff goes into Draw 
section? Or each request should start with blue description name? 
If you want to divide it into categories, we might need more of them 
- e.g. where to put stuff like Top Window Transparency, Multimedia 
Timers (not sure that one belongs there, but I want to have it somewhere)

hehe, added first request :-)

I've made a func to calculate the challengin code given the header 
request.

It was in the "I'm new" section, but it works nicely, I'm using it 
very often, so it's well tested.


ws-chall: funct [header [string!]] [		
	
	cnt: funct [k] [
		n: copy "" 
		ns: 0 
		repeat x k [
			if all [x >= #"0" x <= #"9"][
				append n x
			] 
			if x = #" " [
				ns: ns + 1
			]
		]
		if ns = 0 [
			return none
		]			
		(to decimal! n) / ns
	]
	
	int-2-char: funct [n [integer! decimal!]] [
		;n: to decimal! n
		head insert insert insert insert make string! 4
			to char! n / 16777216
			to char! (n // 16777216) / 65536 
			to char! (n // 65536) / 256
			to char! n // 256
	]

	attempt [
		t: parse/all replace/all header crlf lf "^/"

  l: copy [] repeat x t [if n: find x ":" [insert tail l reduce [copy/part 
  x (index? n) - 1 next n]]] l: head l
		k1: next select l "Sec-WebSocket-Key1"
		k2: next select l "Sec-WebSocket-Key2"
		k3: next next find header "^/^/"
		aux1: cnt k1
		aux2: cnt k2
	]

	if any [none? aux1 none? aux2 none? k3] [return ""]

 to-string checksum/method rejoin [int-2-char aux1 int-2-char aux2 
 k3] 'md5		
]

Thanks for the code, but the handshake implementation was trivial. 
My current issue is the fact that the new ws draft is breaking HTTP 
specifications by using a GET request with a message body...WTF?

I'm not the only one to find that odd: http://blog.iworks.at/?/archives/69-WebSockets-Handshake-non-HTTP-conforming.html

Still, I can't make Cheyenne work as non-root user : the HTTP log 
file keeps being written as root:root even if the main Cheyenne process 
is own by a non-root user. The culprit seems to be the REBOL helper 
process, forked by the main one during REBOL internal boot process 
(so before starting to run user code). I found no way to setuid this 
child process (seems forbidden by the OS?), so it keeps being owned 
by root...


Here's my typical test case under linux (Ubuntu 8.04, /enpro 2.7.6, 
latest SVN revision,using [user "dk"] in config file). I'm running 
the test from a root shell to avoid issues of sudo with REBOL binaries 
(RAMBO #4306) :

;--- launching  Cheyenne process  ---
[root-:-dknux]:/mnt/dev/Cheyenne# ./cheyenne &
[1] 20179


;--- notice the root process below (the only one that Cheyenne can't 
setuid( ) ---
[root-:-dknux]:~# ps aux
[...]

dk       20179  0.2  1.3   9028  6716 pts/0    S    22:21   0:00 
./cheyenne

root     20180  0.0  0.1   2360   600 pts/0    S    22:21   0:00 
./cheyenne

dk       20182  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20183  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20184  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20185  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20186  0.1  0.9   6264  4968 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20187  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20188  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20189  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

;--- no HTTP log file for now ---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 0

;--- I'm sending a request to http://localhost/---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 1
-rw-r--r-- 1 root root 77 2010-09-09 18:19 default-access.log


The log file belongs to root:root, so it must have been generated 
by process 20180. Killing that process prevents Cheyenne from outputing 
any new log file (but Cheyenne keeps serving all requests). I thought 
that the helper process was only used for enabling async dns requests 
when OS doesn't support it natively?...<vent>Like REBOL GC's rules, 
this helper process remains a mystery even after 10 years of reboling...I 
guess these secrets are worth millions of $ to be kept undisclosed 
so far...</vent>

Any ideas?

Carl, did you see our above discussion on getting Cheyenne to shed 
root access, and my request in R3 Chat to have Library access enabled 
in R2/Core?

What causes this error?


15/9-02:54:33.067-## Error in [task-handler-4721] : Make object! 
[
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'protected-exec
    arg2: 'code
    arg3: [block! function!]

    near: [protected-exec/event request/parsed/file get in session/events]
    where: 'fire-event
] !

You should just "Reset Workers", it's enough to reload all the webapps. 
You should also consider running your dev instance of Cheyenne with 
-w 0 command-line option to make it reload all apps on each request.

yes, the -w 0 option asks Cheyenne to maintain a pool of 0 worker 
process and launch one only when required (killing it when the request 
is completed). That has the side-effect or "reloading" all webapps 
and cleaning any corrupted data in memory produced by user-scripts.

Traditional CGI, where you start a new process for each request

Hi Oldes, good point, I was thinking about adding a worker processes 
user-controlled killing policy since years now, but it  has never 
bothered me on my production linux servers. 


Also, if you use the -w command line option, you can (in theory) 
set the threshold for workers kept alive after each request. In practice, 
a worker gets killed only if the threshold is reached and after a 
request is processed, so you might have cases, where more workers 
than should be, remains temporary after a burst of requests.


If it's really an issue for you, I can have a look at this feature 
to see if there's a simple way to implement a killing policy (would 
decrease the number of worker processes using 1 / t or e^(-t) function 
classes). See function plots at :
http://www.wolframalpha.com/input/?i=1+/+t
http://www.wolframalpha.com/input/?i=e^-t

Btw, Cheyenne resets all CGI ENV variables after each CGI request 
for security concerns, so don't be surprise to not be able to see 
them from shell.

So the answer is indeed that this is nothing more than a normal request 
yielding a response, where the response happens to be JSON or maybe 
even full JavaScript. This depends entirely on your own server and 
client programs, not on the intermediating web server

There's no need for session affinity internally in Cheyenne, the 
session context is carried with the request to any worker process.


CGI/RSP requests are dispatched to any available worker process. 
If all are busy, a new one is forked up to the maximum number (8 
by default). If the max number of workers is reached and all are 
busy, the request is queued (the queue is global). Once a worker 
becomes available, it gets a new request assigned at once.

yeah perhaps... is there a ticket for that request ?

60 Concurrent users is a lot - except if they're idling for five 
minutes between every request

Given this JS

					if ( bValid ) {

       var dataString = 'pain=' + pain + '&ptgl=' + gs + '&fn=' + fn + '&rapid3=' 
       + rapid3 + '&fatigue=' + fatigue + '&ros=' + ros + '&ems=' + ems 
       + '&patient=' + '<%=patient%>' ;
						//alert (dataString);return false;
						$.ajax({
							type: "POST",
							url: "add-rapid3.rsp",
							data: dataString,
							success: function() {
							 	// removed ...
							}
						});
						return false;
  
						//$( this ).dialog( "close" );
					}
				},

what would cause this?


28/12-23:58:37.055-[DEBUG] c: [pain "[object Object]" ptgl "[object 
Object]" fn "[object Object]" rapid3 "[object Object]" fatigue "[object 
Object]" ros "[object HTMLInputElement]" ems "[object Object]" patient 
"7"]

where the add-rapid3.rsp is

<%
	; add-rapid3.rsp
	c: request/content
	?? c
	exit
%>

This is my target script add-rapid3.rsp

<%

context [
	d: now
	; convert to gmt, and then to NZ time
	d: d - d/zone + localzone
	?? d
	; add-rapid3.rsp
	c: request/content

 ; c: [pain "3" ptgl "4" fn "2" rapid3 "5" fatigue "9" ros "6" ems 
 "7" patient "7"]
	?? c
	patient: select c 'patient
	pain: min 10 to-decimal select c 'pain
	fn: min 10 to-decimal select c 'fn
	ptgl: min 10 to-decimal select c 'ptgl
	ros: min 60 to-decimal select c 'ros
	fatigue: min 10 to-decimal select c 'fatigue
	ems: min 360 to-integer select c 'ems
	
	result: make object! [
		patient: (patient)
		pain: (pain)
		fn: (fn)
		ptgl: (ptgl)
		ros: (ros)
		fatigue: (fatigue)
		ems: (ems)
	]
	?? result
]	
	
%>

and the c is the dump from ??

I can't get cheyenne to serve to an ajax json request.


I can get it to read the array as a local file but it does not seem 
to work through url request.


I played with content-type: application/json which I read was needed 
but I don't know if I'm on the right track.

Additional Notes:

Due to browser security restrictions, most "Ajax" requests are subject 
to the same origin policy; the request can not successfully retrieve 
data from a different domain, subdomain, or protocol.

Script and JSONP requests are not subject to the same origin policy 
restrictions.

Complicate expressions to tell you about a request blocking new feature 
with pattern recognition (see Changelog, look for "block").

feature request :  I would loke to have some configs (in httpd.cfg) 
for controling things like the verbosity and logging.

I think I have found an issue with /Core 2.7.8 on OS X, the READ-CGI 
mezz is missing! That's making Cheyenne (rev 127) crash on any CGI 
script request.

Doc,    wrt handler.. it really was a stupid error on my part... 
I didn't set the   req/out/code   so I guess it stays in limbo in 
its worker handling, since its not valid for request handling, but 
it has no return error code for reply handling either...

Max: req/out/code is used by HTTPd.r service to know if the request 
is ready or not to be sent back ;-)

i was thinking making a webapp which returns on-page-end the to-json 
context load rejoin [%. request/parsed/file %.r]

capturing 404 doesn't work because it won't know the url of the original 
request

the POSTed and the QUERY-STRING seems to be concatenated in the request/content

this is my rsp: <% print to-string request/content %>

and this is the http request:  curl  -d '{"a": 1, "b": 2}' http://localhost:8080/?test

json.rsp: <% print to-string request/content %>


>> probe read/custom http://localhost/json.rsp[POST {{"a": 1, "b": 
2}}]
connecting to: localhost
{{"a": 1, "b": 2}}

json.rsp:
<%= probe request/content %>
<%= probe as-string request/parsed/arg %>
<%= probe as-string request/parsed/content%>
<%= probe request/parsed/arg %>


>> probe read/custom http://localhost/json.rsp?test[POST {{"a": 
1, "b": 2}}]
connecting to: localhost
{[{"a": 1, "b": 2} "" test ""]{"a": 1, "b": 2}test
{{"a": 1, "b": 2}}{"a": 1, "b": 2}
{{"a": 1, "b": 2}}{"a": 1, "b": 2}
test
test
}


Some corruption is occurring, request/parsed/* should be left untouched.

Ok, false alarm, no bug in RSP request decoder:

json.r
<%= mold request/content %>
<%= mold as-string request/posted %>
<%= mold as-string request/parsed/content %>
<%= mold request/parsed/arg %>


>> print read/custom http://localhost/json.rsp?test[POST {{"a": 
1, "b": 2}}] none
connecting to: localhost
[{"a": 1, "b": 2} "" test ""]
{{"a": 1, "b": 2}}
{{"a": 1, "b": 2}}
test

The <%= in addition to PROBE was producing a misleading output.

Extending the req/in object! is a good solution. I should maybe add 
a 'user field in request object for storing custom mod data...

don't know, since then more than one mod might start to clobber it, 
and we'd be fighting for the space (same difference, just one level 
down  ;-)


and, since those extra bytes get molded/sent/loaded to and from handers... 
it seems like waste when for most people this data will not be used. 
   I'd actually rather document how a module should expand a request... 


like spelling any new word, starting with the mod's name to prevent 
collisions.

Doc, one thing I have not yet fully mapped out in my mind wrt handlers.

Q1:

how do the handlers actually compile/get their source code... is 
it sent over tcp and run there, or does the handler load a file on 
its own?

Q2:
when exactly does this happen?

Q3:

can I configure the handler source or data in some way before it 
gets compiled/executed,  (at the mod conf parsing stage).


I neet the handler to share some data with the mod which manages 
it in some way.


I don't want to send this config data via the request, at each request 
(makes no sense)

yeah... I've changed my solution a bit.   the handler now has a variable 
to know if its been configured yet, and if it has, it skips that 
part of the code.   so even if I get the cfg at each request, I ignore 
it.


The cool thing is that my mod really doesn't need much configuration 
and most other standard configs are useless to it, so I commented 
just about all of them in my httpd.cfg and my mod still works.  :-)


very lean on the cheyenne side.  I do all the heavy lifting in the 
handler, so it can scale pretty well.

i have an rsp like this:

<% probe delta-time [ ... switch request/method [ get  [...]   post 
[...] ]  ... ] %>

if i make a GET, it's fast:

$ time curl -s -D- http://localhost:8080/docs/rfq3 >/dev/null
0:00:00.003815
real    0m0.026s


if i make a post, the rsp part is still fast, but the overall request 
is damn slow (even consequent requests too):

$ time curl -d @xxx -D- http://localhost:8080/docs/rfq3
0:00:00.004595
real    0m2.034s

personally, i never had to use such negotiations which wouldn't accept 
a request..

onetom ~/rebol/delete $ cat httpd.cfg 
modules [ internal extapp static rsp alias ]
globals [ listen [8888]    bind RSP to [ .r ] ]
default [ debug root-dir %./ alias "/test" %test.r ]

onetom ~/rebol/delete $ cat test.r 
<% print request %>


onetom ~/rebol/delete $ rm chey-*.log; rebol -qws ~/rebol/cheyenne-server-read-only/Cheyenne/cheyenne.r 
-w 0 -vvv


onetom ~/rebol/delete $ curl -X DELETE -D- http://localhost:8888/test
HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:14:04 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>


>> p: open/no-wait/direct tcp://localhost:8888
>>  insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:17:34 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>}



u were doing 1.0 DELETE request though, but it didn't make any difference.

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
U    mods/mod-action.r
Updated to revision 131.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

There is no 'mime-type in the request object, only 'mime?? Maybe 
you were thinking about the 'set-mime-type callback?


Lit-path: for historical reason, I wanted to be able to manage content-types 
using mime classes (text/*, image/*,application/*, ...), but I didn't 
use it so far.

ok, probably im trying to do something forbidden there


6/5-17:27:41.971934-[Logger] New request: T6/5-17:27:41.948903-## 
Error in [task-handler-55484] : Make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [switch debug-banner/opts/error [
            inline [html-form-error err file] 
            popup [debug-banner/rsp-error: make err [src: file]]
        ]]
    where: 'protected-exec
] !

By the way, I still want to get rid of the loading of the REBOL CGI 
script on each request, even though I've minimised its size. It's 
a fallback script that now executes in the not-found handler. If 
I would change it from a fast-rebol-cgi script to an .r script, and 
put it in an ALIAS handler, would that preempt the loading of the 
script one each request? I'm not using the RSP interface, so the 
loading of that would be extra overhead. Would it still be faster 
than loading the small fast-rebol-cgi script?

I mean, RSP templates are cached, right? So are the new .r files 
cached, too, instead of loaded on each request like CGI scripts?

So do you think preparing the RSP interface for each request would 
still be faster than reading a small rebol-fast-cgi file every request?

set 'do func [[catch] value	/args arg /next /global /local depth][	
...
			if arg: find apps request/config/root-dir [

Also, about using plain REBOL scripts in RSP engine, it was a last 
year request from Carl, it wasn't part of my planned feature list 
to support, so it can cause new issues that I have not forseen when 
building the RSP engine. You are the first one to report me issues 
with such scripts, so I guess nobody except you and Carl are using 
this approach. Anyway, your reports are helping me make it more reliable.

Basically, your issue is related to the Cheyenne "debug" mode that 
restart all workers after each request. In normal mode (persistant 
workers), it should work fine.

on each request actually

Means a 30x HTTP code was returned by the request.

Have you looked into the request/response logs from Cheyenne?

You should try to send a GET request first on the login.rsp page.

Ok, so if you get a new "Connection closed", it means a new HTTP 
request was sent to Cheyenne.

i would need the request/query-string functionality but on my own 
parameters which has nothing to do w the request params

Untested, but should work: 

build-query: func [url [url!] spec [block!] /local cnt][
    cnt: request/content
    request/content: reduce spec
    also 
        rejoin [url "?" request/query-string]
        request/content: cnt
]


response/redirect build-query http://maps.google.com/maps['saddr 
closest/address 'daddr params/dest]

okay, thanks... i was thinking about creating an empty request somehow. 
that would have been simpler. otherwise i would just overwrite the 
content...

if you have to re-compress the file on each request

60 ms for a single request is way too much.

that request takes several seconds to download in the mentioned scenarios..

this cross site request crap would require the handling of OPTION 
methods too for the so called preflight request which tells the browser 
what can it expect from the "other origin" -- just saying

Re compression: after a deeper look, there is no way to support "on-the-fly" 
compression of static files without totally killing Cheyenne performances. 


If it is done in a mod, it will totally freeze Cheyenne on every 
CALL. If it is done in an handler, most of benefits from the async 
I/O main engine is lost, and Cheyenne will be limited to serve small 
files only (they will be transfered from workers to main process) 
and limited to 1 request per worker (so if 4 workers, maximum simultaneous 
request = 4, all others will be put in queue and waiting).


So, the only way to support static file compression is by pre-compressing 
files and adding some config options to let Cheyenne know which files 
are compressed (file sufix alone is not enough). Pre-compressing 
means having to manage compressed versions of static files (When 
and how to compress? Where to put the files? When to delete them? 
etc...)

I have tried to use the testapp on Dockimbels request, but it serves 
only non-functioning rsp pages on http://hmkdesign.dk.

If you are within a Webapp, probe request/config will return virtual 
root.

But outside webapp, probe request/config will return root-dir defined 
in httpd.cfg

Thanks for the response Gabriele, but I just can't get this to work.
If i'm using an rsp page to send back the request:
I've got this:
<%
data: {
one
: "Singular sensation",
two
: "Beady little eyes",
three
: "Little birds pitch by my doorstep"
}
response/set-header 'Content-Type "application/json"
print rejoin ["myfunc" "({" data "})"]
%>

Does not work...

response in web page includes the function name which does not look 
like json data typically served back

Just one question, nothing urgent. Would it be possible or smart 
if cheyenne would return http 401 to ajax request when the session 
times out? Now it basically return 200 and login form html (so I 
have to test for presence of </form>) instead of usuall JSON.

How can Cheyenne know that's an "ajax request"?

yes, that question crossed my mind :) ... maybe this should hold 
only if request has: "Accept: application/json"

What if the request has other mime-types in addition to that one? 
:-)

Endo, thanks for the code. I will need something similar for sqlite. 
I just got a first db is locked error yesterday with it at UsrJoy.


What I'm trying to log is side-info (like usage info) so I don't 
want to inpact the speed of response by having aditional disk write 
in the request-response process (it has to be async).


Doc: I used debug functions for various info logging too now (and 
I do diff on trace in cron and send myself email if there is any 
difference), but I am trying to log more things and I would like 
to leave trace.log for errors only. I was interested if the existing 
functionality that serializes debug to trace.log could be used to 
log to some other file. like info.log . That would complicate the 
app-code the least.. otherwise I was thinking of what  Kaj  proposed, 
to have some queue to send data over via tcp to and it will write 
it to disk in intervals. That would bring another dependancy into 
app-code.. something like redis could automatically work like this 
I think.

0MQ is already heavily async, and you can make the request/response 
pattern not wait

OK. I saw it as a REBOL process was suddenly racing at 100% CPU. 
Someone accessed my site, which posted an entry in the default-access.log 
with an HTTP 1.0 request:


74.52.168.98 - - [25/Dec/2011:10:30:29 +0100] "GET / HTTP/1.0" 200 
9


Then 5 minutes later, the none-access.log appears and I'm flooded 
with requests until that log is 45 MB in size.

The file starts like this:

.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
74.52.168.98 - - [25/Dec/2011:10:35:54 +0100] "" 405 -
.... 45 MB of this

Hmm, intriguing...Seems that you received a request with garbage, 
either an attack or flooding attempt. The HTTP/1.0 suggests that 
the request is not coming from a web browser (all are using HTTP/1.1 
now).

That could explain the "none-access.log" file, if the request doesn't 
have a Host field defined.

My guess is that some HTTP/1.0 request with data but without Host 
or Content-length field might trigger this bad behaviour from Cheyenne.

Truncation: that could be caused by a bug in the HTTP access log 
batch writing, the log cache seems to have been desynchronized by 
the request.

I've tried a lot of different hand-crafted request to try to crash 
Cheyenne and reproduce your issue, but Cheyenne is keeping responding 
right.

Ah, you're requesting that the math operators apply on blocks of 
scalar (vectors).
Old request.
Never done in R2 and not yet in R3

GFX is part of Host layer, and Host layer is going to be internally 
done using Extensions probably, so your request might be accepted 
:-)

read and write are very similar ... can we do this?

		read: func [
			port [port!]
			/write data
		] [
			either any-function? :port/awake [

    unless open? port [cause-error 'Access 'not-open port/spec/ref] 
				if port/state/state <> 'ready [http-error "Port not ready"] 
				port/state/awake: :port/awake 
				do-request port 
				port
			] [
				sync-op port either write [ data ] [[]]
			]
		] 
		write: func [
			port [port!] 
			value
		] [

   unless any [block? :value any-string? :value] [value: form :value] 

   unless block? value [value: reduce [[Content-Type: "application/x-www-form-urlencoded; 
   charset=utf-8"] value]] 
			read/write port data 
		]

In make-http-request there is this

	result: rejoin [
		uppercase form method #" " 
		either file? target [next mold target] [target] 
		" HTTP/1.0" CRLF
	] 

since it is stated that http 1.1 is being supported, we should change 
this to 1.1

make-http-request  says that content is [ any-string! none! ]
it then converts this to binary.

But if we want to send a binary file using PUT,  I think this must 
mean we need to convert that file to string first ... which seems 
wrong.

Also, if there is no content, then the content-length header is not 
set ... 

Here's my suggested changes at the bottom 


http://rebol.wik.is/Rebol3/Schemes/Http/Prot-http.r/Make-http-request

Just had another thought, if the headers already contain a content-length, 
then make-http-request should not set it again ...

so would I access make-http-request ?

must initiate the path var to get a response from the server:
read [ scheme: 'http path: host: "www.rebol.com" method: 'head]

** Access error: protocol error: "Server error: HTTP/1.1 400 Bad 
Request"

How do you access make-http-request ?  What's the path to this function?

i don't remember when that can happen (i think you should always 
get something if you did a successfull request).

make-http-request is called from the read or write operations. eg. 
write [head %index.html] will make a HEAD request etc.

system/modules/http/make-http-request

I think my proposed changed still stand http://rebol.wik.is/Rebol3/Schemes/Http/Prot-http.r/Make-http-request

IIRC we need UDP to do a DNS request.

# Setup the IO-request data and length fields. Data is the buffer 
tail position. Length is the buffer space available from above. Clear 
the actual field.

The details of the port actor for WRITE are:


   1. Set port/data to WRITE content (binary string) value. (Mainly 
   to keep it GC safe.)

   2. Obtain binary string as specified. The buffer is not copied. This 
   is a low level mechanism.
   3. Determine start position from index.

   4. Determine length from tail-index or from /part if specified.

   5. Set IO-request length and data. Zero the actual field (the length 
   actually transferred).
   6. Call the TCP device with the IO-request
   7. Check for errors

   8. Check for immediate completion. If done, set port/data to NONE.

Check IO-Request connection flag. This is not a socket check, it 
is a request state flag check.
Check the port/data for an existing buffer.

If no buffer found, allocate one that is of the default size (32,000). 
Note: not 32K.
Compute buffer space available.

If available space is less than half the default size, extend the 
buffer.
Recompute buffer space available.

Setup the IO-request data and length fields. Data is the buffer tail 
position. Length is the buffer space available from above. Clear 
the actual field.
Call the TCP device with READ command.
Check result for error. If error, throw it.

you'll have to do a PASV before each new request

if the client is expected to send a request before receiving anything 
from the server, things will look different