Start filling out the request data structures.

This commit is contained in:
Elliot Glaysher 2018-10-25 16:32:54 -07:00
parent 9c4c470b90
commit 6eebffaa25
3 changed files with 137 additions and 10 deletions

View File

@ -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

View File

@ -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

View File

@ -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