Showing changes from revision #2 to #3:
Added | Removed | Changed
Read data pending from a request.
Entry | ||
---|---|---|
R0 | Flags: | |
Bits 31..0 Reserved (0) | ||
R1 | Session identifier | |
R2 | Client buffer for received data | |
R3 | Size of buffer pointed to by R2 |
Exit | ||
---|---|---|
R0 | Status word (see SWI URL_Status) with the addition of protocol-specific flags (see below) | |
R2 | Preserved. Contents of buffer modified | |
R4 | Number of bytes transferred to R2 buffer | |
R5 | Number of bytes still to be read to complete object (if known) or -1 if unknown | |
All other registers preserved | ||
SWI is not re-entrant | ||
Interrupt status undefined |
This SWI is used to read the data pending from a request, find out how much data has been read on this call and how much more there is remaining to be read for the request. R2 is a pointer to a buffer on entry (and R3 is the size of the buffer), on exit the buffer contains the new data, R4 contains the amount of data written to the buffer and R5 contains the amount of data left to be read. If the amount of data left is unknown R5 will contain -1.
R0 always returns the protocol status code (see URL_Status) possibly with the addition of protocol-specific flags. For example, for HTTP and HTTPS requests, the underlying AcornHTTP protocol module will set bit 16 if there are cookies in the queue. These can be read using HTTP_EnumerateCookies.
In the event of all the data being read (R5 = 0 on exit), a call to URL_Stop is not required as this is performed automatically when URL_Deregister is called for the client session. Once all data has been read a call to URL_Status can return no meaningful information, simply indicating that the transfer has completed.URL_Stop is not required as this is performed automatically when URL_Deregister is called for the client session. Once all data has been read a call to URL_Status can return no meaningful information, simply indicating that the transfer has completed.
The data returned will take the form of a complete HTTP compatible response. Responses should use HTTP/1.0 if possible and avoid HTTP/1.1. For example, AcornHTTP will downgrade any higher version responses to HTTP/1.0, having taken care to remove any features applicable only to the higher version, such as chunked transfer encodings.
When this SWI is called, the URL module invokes the Protocol_ReadDataProtocol_ReadData SWI for the protocol module concerned with the request.