From 6eebffaa259343fe0574e8f8ef08119de5409c4f Mon Sep 17 00:00:00 2001 From: Elliot Glaysher Date: Thu, 25 Oct 2018 16:32:54 -0700 Subject: [PATCH] Start filling out the request data structures. --- gen/solid.hoon | 2 +- sys/vane/light.hoon | 77 +++++++++++++++++++++++++++++++++++++++------ sys/zuse.hoon | 68 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 137 insertions(+), 10 deletions(-) diff --git a/gen/solid.hoon b/gen/solid.hoon index 6cb3d48ade..28665c1602 100644 --- a/gen/solid.hoon +++ b/gen/solid.hoon @@ -45,6 +45,7 @@ =+ all=.*(0 ken) =+ ^= vay ^- (list {p/@tas q/path}) :~ [%$ /zuse] + [%l /vane/light] [%f /vane/ford] [%b /vane/behn] [%d /vane/dill] @@ -53,7 +54,6 @@ [%g /vane/gall] [%e /vane/eyre] [%j /vane/jael] - [%l /vane/light] == |- ^+ all ?~ vay all diff --git a/sys/vane/light.hoon b/sys/vane/light.hoon index b69e54da87..7d2a13c700 100644 --- a/sys/vane/light.hoon +++ b/sys/vane/light.hoon @@ -69,7 +69,7 @@ ship=(unit ship) :: client-state: state of outbound requests :: - ::=client-state + client-state=state:client :: server-state: state of inbound requests :: =server-state @@ -86,19 +86,17 @@ next-id=@ud :: connection-by-id: open connections to the :: - connection-by-id=(map @ud [=duct =http-request]) + connection-by-id=(map @ud [=duct =in-progress-http-request]) == :: +in-progress-http-request: state around an outbound http :: +$ in-progress-http-request $: :: remaining-redirects: http limit of number of redirects before error :: - remaining-redirects=_5 + remaining-redirects=@ud :: remaining-retries: number of times to retry the request :: - :: TODO: We can't just retry by default. We might only - :: - remaining-retries=_3 + remaining-retries=@ud :: chunks: a list of partial results returned from unix :: chunks=(list octs) @@ -166,7 +164,7 @@ :: [%login-handler ~] == -:: +:: +authentication-state: state used in the login system :: +$ authentication-state $% :: sessions: a mapping of session cookies to session information @@ -177,8 +175,15 @@ :: +$ session $% :: expiry-time: when this session expires + :: + :: We check this server side, too, so we aren't relying on the browser + :: to properly handle cookie expiration as a security mechanism. :: expiry-time=@da + :: + :: TODO: We should add a system for individual capabilities; we should + :: mint some sort of long lived cookie for mobile apps which only has + :: access to a single application path. == -- :: utilities @@ -307,7 +312,38 @@ (easy ~) == == -:: +per-server-event: per-event client core +:: +per-client-event: per-event client core +:: +++ per-client-event + |= [[our=@p eny=@ =duct now=@da scry=sley] state=state:client] + |% + ++ fetch + |= [=http-request =outbound-config] + ^- [(list move) state:client] + :: get the next id for this request + :: + =^ id next-id.state [next-id.state +(next-id.state)] + :: add a new open session + :: + =. connection-by-id.state + %+ ~(put by connection-by-id.state) id + =, outbound-config + [duct [redirects retries ~ 0 ~]] + :: start the download + :: + :: the original eyre keeps track of the duct on %born and then sends a + :: %give on that duct. this seems like a weird inversion of + :: responsibility, where we should instead be doing a pass to unix. the + :: reason we need to manually build ids is because we aren't using the + :: built in duct system. + :: + :: email discussions make it sound like fixing that might be hard, so + :: maybe i should just live with the way it is now? + :: + :: :- [duct %pass /fetch + [~ state] + -- +:: +per-server-event: per-event server core :: ++ per-server-event |= [[our=@p eny=@ =duct now=@da scry=sley] state=server-state] @@ -814,6 +850,9 @@ %born :: ~& [%todo-handle-born p.task] + :: TODO: reset the next-id for client state here. + :: + :: close previously open connections :: :: When we have a new unix process, every outstanding open connection is @@ -872,11 +911,31 @@ =/ cancel-request cancel-request:(per-server-event event-args) =^ moves server-state.ax cancel-request [moves light-gate] + :: + :: %fetch + :: + %fetch + ~& %todo-fetch + =/ event-args [[(need ship.ax) eny duct now scry-gate] client-state.ax] + =/ fetch fetch:(per-client-event event-args) + =^ moves client-state.ax (fetch +.task) + [moves light-gate] + :: + :: %cancel-fetch + :: + %cancel-fetch + ~& %todo-cancel-fetch + [~ light-gate] + :: + :: %receive: receives http data from unix + :: + %receive + ~& %todo-receive + [~ light-gate] :: :: %connect / %serve :: ?(%connect %serve) - ~| [%task task] =/ event-args [[(need ship.ax) eny duct now scry-gate] server-state.ax] =/ add-binding add-binding:(per-server-event event-args) =^ moves server-state.ax diff --git a/sys/zuse.hoon b/sys/zuse.hoon index cdb5461f20..f843d7a4a0 100644 --- a/sys/zuse.hoon +++ b/sys/zuse.hoon @@ -2206,12 +2206,40 @@ :: http-response: response from urbit to earth :: [%http-response =raw-http-response] + :: %http-request: outbound http-request to earth + :: + :: TODO: id is sort of wrong for this interface; the duct should + :: be enough to identify which request we're talking about? + :: + [%http-request id=@ud request=(unit http-request)] :: response to a %connect or %serve :: :: :accepted is whether :binding was valid. Duplicate bindings are :: not allowed. :: [%bound accepted=? =binding] + :: periodically sent as an update on the duct that sent %fetch + :: + $: %http-progress + :: http-response-header: full transaction header + :: + :: In case of a redirect chain, this is the target of the + :: final redirect. + :: + =http-response-header + :: bytes-fetched: bytes fetched so far + :: + bytes-fetched=@ud + :: bytes-total: the total size if response had a content-length + :: + bytes-total=(unit @ud) + :: incremental: data received since the last %http-progress + :: + incremental=octs + == + :: final response of a download, parsed as mime if successful + :: + [%http-finished =http-response-header full-file=(unit mime)] == :: ++ task @@ -2232,6 +2260,15 @@ :: cancels a previous request :: [%cancel-inbound-request ~] + :: fetches a remote resource + :: + [%fetch =http-request =outbound-config] + :: cancels a previous fetch + :: + [%cancel-fetch ~] + :: receives http data from outside + :: + [%receive =http-request complete=?] :: connects a binding to an app :: [%connect =binding app=term] @@ -2309,6 +2346,24 @@ :: redirect=? == + :: +outbound-config: configuration for outbound http requests + :: + +$ outbound-config + $: :: number of times to follow a 300 redirect before erroring + :: + :: Common values for this will be 3 (the limit most browsers use), 5 + :: (the limit recommended by the http standard), or 0 (let the + :: requester deal with 300 redirects). + :: + redirects=_5 + :: number of times to retry before failing + :: + :: When we retry, we'll automatically try to use the 'Range' header + :: to resume the download where we left off if we have the + :: 'Accept-Range: bytes' in the original response. + :: + retries=_3 + == :: +| %http :: +header-list: an ordered list of http headers @@ -2345,6 +2400,19 @@ :: body=(unit octs) == + :: +http-response: the status code and header list on an http request + :: + :: We separate these away from the body data because we may not wait for + :: the entire body before we send a %progress to the caller. + :: + +$ http-response-header + $% :: status: http status code + :: + status-code=@ud + :: headers: http headers + :: + headers=header-list + == :: +raw-http-response: http-response to sent to earth :: :: Urbit treats Earth's HTTP servers as pipes, where Urbit sends one or