HTTP request implementation
From OpenLaszlo
Contents |
Specificaton
The Laszlo loading system supports the following features:
- request limiting
- request priority
- error notification
- timeout notification
- queueing behavior - whether sending a request cancels previous outstanding requests
- order preservation - whether responses are processed in request order
It supports the following request types:
- library requests (direct and proxied)
- media requests (direct and proxied)
- XML data requests (direct and proxied)
TBD: Whether an error or timeout in one request allows subsequent requests to complete.
Settable Timeouts
See Settable Timeouts.
Design
Loading
When a request is made for data or media, the dataset or view which made it sends an onload event when that load is successful. In general, the internal hidden LzLoader object that makes the request sends on load, and then the original requestor does what it wants once the load is complete, which usually includes sending the onload event.
The LFC actively manages its open connections (since they are a limited resource) and tracks how many requests are open at a given time. Using the API in LzLoadQueue (e.g. addPriorityFunction), it should be possible to change the priority of requests which are added to the queue that can't be made immediately. There is a default priority of the debugger over data, and of data over media.
When an LzLoader has its queuing attribute set to false, it should emulate browser behavior, meaning: if multiple requests are made before the first one comes back, those other requests should be cancelled. If possible, this means that they should never be made. If one or more of those requests have been made, it means that they should be ignored when they come back, and only the last one should send onload.
If queueing is turned on, every request that is made should be made by the LzLoader. Additionally, requests should be returned in the order that they were made even if a later requests actually comes back before a previous one.
The queuing behavior of an LzLoader is controlled by the queuerequests attribute of dataset. Media loading is always done with queuing turned off.
LzLoadQueue.makeRequest is the root for much of the loading queue.
Proxied Operation
When the LPS is acting as proxy, most backend problems are returned to the LFC as load errors. These trigger the onerror event in the LzLoader which is then picked up by the view or dataset which made the request.
When the LPS is acting as a proxy, an ontimeout is sent if no response is sent from the server. This rarely happens and is an unrecoverable failure for most apps. With the addition of unproxied operation, many loading problems will be surfaced as timeouts, since Flash gives very little information about http errors. As such, if a request hasn't loaded in the timeout time, then the LzLoader should abort and send an ontimeout event. Aborting a request should be sure to close the HTTP connection in addition to removing the request from the LFC's internal notion of open requests. This should be tested by timing out a request that takes a long time to make sure that the HTTP connection gets closed.
API Implementation
The data loading timeout can be set via the "dataloadtimeout" attribute on <canvas>. The media loading timeout is set via "medialoadtimeout" attribute. Times are given in milliseconds.
Both default to 30 seconds.
<canvas medialoadtimeout="60000" dataloadtimeout="30000">
The timeout on a data load request can also be set on a dataset or datasource with the "timeout" attribute.
<dataset timeout="15000"> // sets data load timeout to 15 seconds
Testing
Test cases for the load queue are in:
- test/lfc/data
- test/http/data
- test/data
To verify request ordering, push the button repeatedly in test/lfc/data/testhttpdata.lzx.
The queuerequests behavior of datasets is tested in testhttpdata.lzx.
