Commit cbfea359 authored by Stewart Brodie's avatar Stewart Brodie
Browse files

Implementation detail documentation updates to cover recent API changes and...

Implementation detail documentation updates to cover recent API changes and stuff not generally suitable for specification documents.
parent 9e1b4976
......@@ -7,7 +7,7 @@
0. Document history
1. Introduction
2. "Session.headers"
2.1 During Requests
......@@ -17,6 +17,18 @@
5. Data buffers
6. Counters
7. Errors
8. Compression
9. Build options
0. Document History
Date Issue Comments
29/10/97 1 First version
21/04/98 2 Notes about build options added and compression
......@@ -37,6 +49,11 @@ URL_DeregisterURL or URL_Stop) to clean up.
This is the standard fetcher interface, however, many things are done
internally to optimise use of resources, which are described below.
If the AcornSSL module is loaded, then HTTPS fetches are started with
a call to SWI HTTP_SecureGetData (again via URL_GetURL). The SWI names
match those of normal HTTP except with the word "Secure" as a prefix of
the SWI name. These SWIs are based at SWI_base+&10.
2. "Session.headers"
......@@ -196,3 +213,26 @@ and the browser will continue to poll for the remaining data.
Are all stored in the Messages file and read into a static _kernel_oserror
buffer at run-time.
8. Compression
The HTTP protocol has the ability to use on-the-fly compression of entity
bodies being transferred in order to decrease used bandwidth. If the
compression code is enabled (see Build Options) then on-the-fly decompression
will be performed, but, obviously, only in transfers where the server has
noticed our declaration of decompress capability and taken advantage of it.
9. Build Options
Several features of the AcornHTTP module can be controlled through the use
of pre-processor macros. These are set in the Makefile in the DFLAGS macro.
Currently, only COOKIE and COMPRESSION should be altered.
COMPRESSION controls the ability to handle compressed transfers as described
above. COOKIE controls the ability to process cookies. If an application
is running in an environment where it wishes to handle all the cookie stuff
itself, it can do so by using a build of this module which does not include
the cookie code.
......@@ -3,6 +3,11 @@
&83F82 SWI "HTTP_ReadData"
&83F83 SWI "HTTP_Stop"
&83F90 SWI "HTTP_SecureGetData"
&83F91 SWI "HTTP_SecureStatus"
&83F92 SWI "HTTP_SecureReadData"
&83F93 SWI "HTTP_SecureStop"
&83FBF SWI "HTTP_EnumerateCookies"
&83FBE SWI "HTTP_ConsumeCookie"
&83FBD SWI "HTTP_AddCookie"
......@@ -9,11 +9,17 @@ Meaning of flags in R0 on entry to this SWI are:
bit 0 set: R6 points to alternative user agent identifier
bit 1 set: R5 is the length of data pointed to by R4 (if R4 not zero)
bits 2-7 : reserved
bit 29: reserved for internal use (secure connection flag)
bit 30: reserved for use by WebServe (request to not add cookies)
bit 31: reserved for use by URL module (if set, this is a proxy request)
Methods in bottom 8 bits of R2 are (NOT a bitfield)
1: GET
3: reserved - do not use
5,6,7: reserved - do not use
8: PUT
Bits 8-15 of R2 are the type of data wanted (if R0:1 set, else in bits 0-31 of R5)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment