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.

Docs/ImpDetails

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

Docs/SWInums

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

Docs/SWIs

@@ -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
           2:   HEAD
+          3:   reserved - do not use
           4:   POST
+      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)