World: r3wp

later ..

ie. is prot-http.r generated from the rebol literate programming 
document?

prot-http.r is the latest. prot-http.rlp was just uploaded later.

The original prot-http.r was generated from .rlp, but has since been 
revised directly. Look at the revision history with LF and DIFF.

ok,  I see this

        spec/headers: third make make object! [
in the rlp, and in the .r

	spec/headers: body-of make make object! [

so they are different.

body-of would work, third wouldn't.

so the rlp is correct?  and the .r is not ?

reverse that ...

The .rlp version is more than 2 years old, the .r is more recent 
and works.

oh ...ok.

works, sort-of, still needs work.

spec/headers: body-of make make object! [
		Accept: "*/*" 
		Accept-Charset: "utf-8" 
		Host: either spec/port-id <> 80 [
			rejoin [form spec/host #":" spec/port-id]
		] [
			form spec/host
		] 
		User-Agent: "REBOL"
	] spec/headers 
what exactly is this code doing?

Makes a object containing the standard http headers derived from 
the template object, also defined in a literal spec.

Has an extra object of overhead.

so spec/headers contains the standard template, and it adds these 
other members to this template?

Yeah, I think so. I shoud check for sure. This is why I am starting 
woth mezz-ports.r first.

Something looks reversed, like spec/headers is using the specific 
headers as a template rather than the reverse. Don't know why yet.

So, it is modifying the original spec/headers by adding these new 
members to spec/headers ...  as a way of modifying the object in 
situ as it were

I wonder why he can't do this 

spec/headers: make spec/headers [
		Accept: "*/*" 
		Accept-Charset: "utf-8" 
		Host: either spec/port-id <> 80 [
			rejoin [form spec/host #":" spec/port-id]
		] [
			form spec/host
		] 
		User-Agent: "REBOL"
]

oh ... headers is a block and not an object!

I think that the Accept, Accept-Charset and User-Agent headers are 
the defaults, and spec/headers are the user-specifiable options.

So he is using make object! to ensure that he has unique members 
in the created block!

Actually, an object is created. Then it is converted to a string 
later.

Yeah .. seems a rather round about way of doing things.

There are a lot of interesting tricks you can do with objects that 
are much trickier with string-format headers. It's worth it.

We can look into reducing the overhead though.

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

yeah ... some function that appends one block of set pairs to another 
without overwriting the original ...

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.

we should allow binary! as well ... and change the code to 

if content [
		if string? [ content: to binary! content ] 
		repend result ["Content-Length: " length? content CRLF]
	]

if content [
		if string? content [ content: to binary! content ] 
		repend result ["Content-Length: " length? content CRLF]
	]

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

1.1 didn't work since chunked encoding was broken, so they reverted 
to 1.0. Proper 1.1 support is on the list to fix.

However, chunked encoding needs to be fixed first, before 1.1 support 
can be reenabled.

The .rlp http client was also written before the Unicode changes 
were finished, so we need to review for those fixes too.

That would affect the string-vs-binary situation.

I'm looking at the .r source ...

Which has only been patched a few times, not yet properly reworked.

well, I think not setting the content-length header might be bug 
..

eg .. with the HEAD verb

Only if you aren't using chunked encoding. If you are, then setting 
Content-Length would be a bug.

Is this going to be rewritten so that we can stream files using PUT?

Sure. And it's going to be rewritten so that http server mode is 
supported too.

In an event handler sort of way though - no assumptions that there 
are going to be files that are being served. You could build a new 
Cheyenne on it, but it won't compete with Cheyenne itself.

It's more for web service application control interfaces than it 
is for generic web serving.

actually where is stuff defined anyway?  It appears in prot-http.r 
but it's not there when your probe the scheme...

Just thinking that if you need to create signed headers eg. for Amazon 
requests, then these functions should be readily accessible rather 
than tucked inside a scheme somewhere

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

This would be where you are PUT ing a binary file and you already 
know the length, so you set it in the spec ...