World: r3wp

port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    switch/default event/type [
        read    [prin "read:"    copy  port]
        lookup  [prin "lookup:"  query port open port]
        wrote   [prin "wrote:" ]
        connect [prin "connect:" read  port]
        ready   [prin "ready:"   close port]
        custom  [prin "custom:"]
        done    [prin "done:"  ]     
        close   [prin "close:" ]
        error   [prin "error:" ]
        custom  [prin "custom:"]
    ][
        true
    ]
]
open port
wait port

gives

connect:wrote:read:custom:** Script error: res: needs a value

** Where: either case check-data either switch check-response switch 
applier wake-up loop applier wait catch either applier do vv
** Near: either headers/content-length <= length? port/data [
    sta...

in prot-http.r, in http-awake function, there is a switch statement

res: switch state/state


try adding a switch/default instead

and use 'none for the default to see what happens

and probe state/state to see what value might be causing this error

HTTP-AWAKE is the event handler for the underlying TCP port, from 
my understanding the awake handler for the HTTP scheme should be 
way simpler.

I'm getting better results with

port: make port! http://www.rebol.com
port/awake: funct [event] [
    port: event/port
    prin join event/type ":"
    
    switch/default event/type [
        connect [read  event/port false]
        ready   [read  event/port false]
        read    [query event/port false]
        custom  [copy  event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port

That gives the following output:

connect:wrote:read:read:custom:done:

But at the 'DONE EVENT/TYPE it then hangs. By returning TRUE there 
the AWAKE handler normally should awake the port, making the WAIT 
return.

this is true for a tcp port, but this is a http port, and Gabriele 
has two handlers there, one of which is creating custom events.

Since your code is handling custom events, I presume that you're 
handling the events generated by the main awake handler ...

Ok, this is confusing, and it doesn't help that I have absolutely 
no expertise in that networking stuff. It doesn't help, I'll have 
to dive in anyway. So excuse me when occasionally I come here panting 
for some air before drowning ;-)

It seems to work fine, reading the page like it should:

port: make port! http://www.rebol.com
port/awake: funct [event] [
    prin join event/type ":"
    
    switch/default event/type [
        connect [read event/port false]
        ready   [read event/port false]

        read    [probe length? event/port probe query event/port false]
        custom  [probe to string! copy event/port false]
        done    [true]
        close   [true]
    ][
        false
    ]
]
open port
wait port

It just doesn't return when it's DONE. Even though the last state 
is that DONE state and the awake handler returns TRUE. Reading further 
...

The CUSTOM event/type is generated by the lower level TCP awake handler, 
with event/code set to zero when transfer is completed. So, TCP-awake 
calls HTTP-awake with an event with event/code:0 and event/type: 
'custom

And it makes no difference if at that point I return TRUE or FALSE, 
the wait hangs

To me, it almost looks like things aren't working "as advertised", 
which may be because docs and code aren't properly sync'ed.

Graham: I suspect that your problem is simply that you have to wait 
on all the ports (including events), not just the network port. Don't 
forget that R2 has a "hidden" list of extra ports to wait for (system/ports/wait-list), 
while R3 does not AFAIK

Yes, that's what I'm after, Gabriele. Opening a network port and 
then waiting for network, time, or gui events.

Christian: does the example on the wiki work? If not, then something 
has been changed since then, and I can't help much without studying 
everything back again. If so, then maybe we can figure out why your 
version does not work.

studying your own code ?  :)

ie. this one:

   port: make port! http://www.rebol.com/
   port/awake: func [event] [
       switch event/type [
           connect [read event/port]
           done [print copy event/port return true]
       ]
       false
   ]
   open port
   wait port

Graham: mostly, the changes in R3, and trying to figure out how it 
works now. It's not like there are docs with enough details...

Gabriele, that's the main point of confusion to me, that even that 
example fails. I.e.. hangs when DONE, in the same way as my attempts 
on this.

Ok, so it's not your fault. R3 has changed and the HTTP scheme does 
not work correctly anymore.

Good to know. I like the line "It's not like there are docs with 
enough details..."

I think I read somewhere Brian saying that http had to be modified 
as chunked encoding didn't work or something like that

But the source was modified and not the rlp

IIRC http was degraded to 1.0 from 1.1 due a problem Graham describes 
...

Isn't there a source code revision history somewhere??

so we can see exactly what was changed?

Looks like we need a set of unit tests for the protocols ...

All changes to the source are in DevBase.

devbase??

last contribution to devbase was 1 mar 2009 by yourself

More likely than changes to the http-prot source being the reason 
for the async behaviour not working as expected are changes to the 
core itself.

That's my guess.

I tried against Gabriele's original pto-http sources as from the 
*.rlp, not the *.r as touched by Carl. Only thing I changed was two 
replacements of THIRD with BODY-OF.

No luck even with older R3 versions; version 2.100.33.3.1 dating 
back to 2009-01-28 being the oldest I have around.

*pto-http = prot-http

Graham, all changes to the prot-http sources seems to be authored 
by Carl, I've seen no traces of changes to the protocol introduced 
by Brian.

Andreas and I did the same, doing a diff on the original prot-http 
and current and found no major changes.  Suggest submit a bug report.

DevBase is the forum/filestore that you access withg the CHAT command 
in R3.

I haven't posted changes to the http protocol yet, sorry.

Brian, I guess you are talking about changes that are also not yet 
in R3?

Ah, nevermind. Upon re-reading, I think I misunderstood your message.

Right. The http scheme is due for a major revamp. What we have is 
not really all that we want.