World: r3wp

But if I do a wireshark trace, I see this

GET /20090806.7z HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.6.3.1
Host: remr.s3.amazonaws.com

HTTP/1.0 403 Forbidden
Date: Sat, 08 Aug 2009 21:08:07 GMT
Content-Type: application/xml
x-amz-request-id: D03B3FA12CC875D5

x-amz-id-2: u3b7TkPzJc5NBwvov4HRQuMsCsosD7le9xfRMSGiCN2BXgeae6kKMVQAbhzqRDwY
Server: AmazonS3
Via: 1.1 nc1 (NetCache NetApp/6.0.5P1)

<?xml version="1.0" encoding="UTF-8"?>

<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>D03B3FA12CC875D5</RequestId><HostId>u3b7TkPzJc5NBwvov4HRQuMsCsosD7le9xfRMSGiCN2BXgeae6kKMVQAbhzqRDwY</HostId></Error>

So, the http protocol is getting all of this information, but is 
throwing it away and only raising an error.

I'm going to add 

403 success 


to the prot-http.r response-actions to see if there are no side effects.

and while I'm at it ..

400 success ; bad request

No, the HTTP scheme is working correctly. AWS' behavior is non-standard, 
so it requires some level of custom programming. R3's scheme allows 
you to handle cases like this at a lower level for example, but by 
default it can't do better than that.

this is http 1.0 http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code403

403 Forbidden


The server understood the request, but is refusing to fulfill it. 
Authorization will not help and the request should not be repeated. 
If the request method was not HEAD and the server wishes to make 
public why the request has not been fulfilled, it should describe 
the reason for the refusal in the entity body. This status code is 
commonly used when the server does not wish to reveal exactly why 
the request has been refused, or when no other response is applicable.

The pertinent line in this is "it should describe the reason for 
the refusal in the entity body." so it looks to me that AWS's behaviour 
does conform to the standard as it is supplying the reasons in  the 
entity body.

Anyway, making the above patch now returns the error in the body 
where I want it .. though don't necessarily need it!

I'm more interested in debugging bad requests ... where Amazon explains 
the reasons for the bad request in the body returned.

Maybe there should be a default behaviour which is what it is now, 
and another behaviour where one can specify which  codes are not 
be flagged as user errors?

or pehaps an object mode where the whole http response is returned 
as a rebol object

Authorization will not help
. And you think AWS conforms to the standard? :-)

I don't criticize them for not conforming, HTTP is missing decent 
auth mechanisms. But still, that is an error, and should behave, 
by default, as an error. As I said above, for special cases you need 
to override the default behavior. I think that the header and request 
body shoud be available in the port, but it should still throw an 
error.

I can understand the philosophical reasons why you consider it an 
error ... but there are practical reasons also to not consider them 
errors.

http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html#AuthProcess


At the bottom of this page, the Google authentication API can provide 
a 403 response as this example below

HTTP/1.0 403 Access Forbidden
Server: GFE/1.3
Content-Type: text/plain
	
Url=http://www.google.com/login/captcha
Error=CaptchaRequired
CaptchaToken=DQAAAGgA...dkI1LK9

CaptchaUrl=Captcha?ctoken=HiteT4b0Bk5Xg18_AcVoP6-yFkHPibe7O9EqxeiI7lUSN

The client is supposed to read the http body to extract the token 
and captcha url so that they can attempt re-authentication.

Just curious .. but what does the qtask api do when issuing 403s 
?

I don't think the Qtask API issues 403.

still, 4xx is an error no matter what. *any* browser would consider 
that an error. then, you handle it. you can't just expect READ to 
handle it for you, as by the standard, there is no way to handle 
this case (auth required can be handled by asking the user for a 
password).

it would be very nice if proper auth methods were added to HTTP and 
all those APIs were changed to use it, and be RESTful, and so on, 
then maybe we could talk of a standard http scheme that behaves correctly 
"by default".

how things are now, HTTP is (mis)used in varioius ways, and you have 
to handle the exceptional cases yourself.

don't you agree, that the way R3 handles the issue is the best way? 
R2 can probably be made to behave similarly. (I've actually been 
thinking of backporting R3's HTTP for a long time...)

I don't know how R3 handles http .. not looked at it.

I guess I just don't like the idea of a protocol hiding data from 
me,...

what's the difference between 'join and 'rejoin ?

The number of args:
    join "a" ["b" "c"]
    rejoin ["a" "b" "c"]

>> text: "hello world"
== "hello world"
>> bin: make binary! 1
== #{}
>> join text bin
== "hello world"
>> rejoin [ text bin ]
== "hello world#{}"

JOIN takes 2 parameters, REJOIN just takes one, and is slightly slower 
because it has to retrieve the first parameter from what would be 
the second parameter of JOIN.

A different outcome.

Looks like a bug to me, Graham.

Opinions?

Looks like a bug to me too.

R2 work around?
    to-string rejoin [#{} "hello" #{}]
    == "hello"

not for me .. thanks!

I was constructing a payload for a http post, and need a combination 
of string and binary data.  I used rejoin... and got an unexpected 
outcome.

So, I guess I'll just have to use repeated appends instead to build 
the payload.

ajoin: funco [
	"Reduces and joins a block of values into a new string."
	[throw]
	block [block!]
][
	make string! reduce block
]

Faster than JOIN or REJOIN.

Sorry about the funco, I copied that from R2/Forward.

let me guess .. part of your rebol3 backport ??

Of course.

does it build a series without corrupting binary data ??

perhaps i need 'bjoin :)

Yes. The mezzanine is faster than the native version, but the native 
doesn't have the intermediate block overhead.

Where is it?

'funco i.e.

It's just another name for FUNC (where FUNC is redefined in R2/Forward).

ask-brian: funco [ ask-brian ]

oops... missing the second block!

Just use FUNC :)

Nope... seems to give the same problems as rejoin