Fossil SCM
Improvements to the "How CGI Works" page.
Commit
e379665aaf92e278d752423e7498b55b918ff3f0
Parent
c55f54d0fcfaf27…
1 file changed
+30
+30
| --- www/aboutcgi.wiki | ||
| +++ www/aboutcgi.wiki | ||
| @@ -180,5 +180,35 @@ | ||
| 180 | 180 | a repository. The PATH_INFO is shortened by removing |
| 181 | 181 | "subdir/three/" leaving it at just "timeline". |
| 182 | 182 | <li> Fossil looks at the rest of PATH_INFO to see that the webpage |
| 183 | 183 | requested is "timeline". |
| 184 | 184 | </ol> |
| 185 | +</blockquote> | |
| 186 | +<h2>Additional Observations</h2> | |
| 187 | +<blockquote><ol type="I"> | |
| 188 | +<li><p> | |
| 189 | +Fossil does not distinguish between the various HTTP methods (GET, PUT, | |
| 190 | +DELETE, etc). Fossil figures out what it needs to do purely from the | |
| 191 | +webpage term of the URI. | |
| 192 | +<li><p> | |
| 193 | +Fossil does not distinguish between query parameters that are part of the | |
| 194 | +URI, application/x-www-form-urlencoded or multipart/form-data encoded | |
| 195 | +parameter that are part of the POST content, and cookies. Each information | |
| 196 | +source is seen as a space of key/value pairs which are loaded into an | |
| 197 | +internal property hash table. The code that runs to generate the reply | |
| 198 | +can then reference various properties values. | |
| 199 | +Fossil does not care where the value of each property comes from (POST | |
| 200 | +content, cookies, or query parameters) only that the property exist | |
| 201 | +and has a value. | |
| 202 | +<li><p> | |
| 203 | +The "[/help?cmd=ui|fossil ui]" and "[/help?cmd=server|fossil server]" commands | |
| 204 | +are implemented using a simple built-in web server that accepts incoming HTTP | |
| 205 | +requests, translates each request into a CGI invocation, then creates a | |
| 206 | +separate child Fossil process to handle each request. In other words, CGI | |
| 207 | +is used internally to implement "fossil ui/server". | |
| 208 | +<p> | |
| 209 | +SCGI is processed using the same built-in web server, just modified | |
| 210 | +to parse SCGI requests instead of HTTP requests. Each SCGI request is | |
| 211 | +converted into CGI, then Fossil creates a separate child Fossil | |
| 212 | +process to handle each CGI request. | |
| 213 | +</ol> | |
| 214 | +</blockquote> | |
| 185 | 215 |
| --- www/aboutcgi.wiki | |
| +++ www/aboutcgi.wiki | |
| @@ -180,5 +180,35 @@ | |
| 180 | a repository. The PATH_INFO is shortened by removing |
| 181 | "subdir/three/" leaving it at just "timeline". |
| 182 | <li> Fossil looks at the rest of PATH_INFO to see that the webpage |
| 183 | requested is "timeline". |
| 184 | </ol> |
| 185 |
| --- www/aboutcgi.wiki | |
| +++ www/aboutcgi.wiki | |
| @@ -180,5 +180,35 @@ | |
| 180 | a repository. The PATH_INFO is shortened by removing |
| 181 | "subdir/three/" leaving it at just "timeline". |
| 182 | <li> Fossil looks at the rest of PATH_INFO to see that the webpage |
| 183 | requested is "timeline". |
| 184 | </ol> |
| 185 | </blockquote> |
| 186 | <h2>Additional Observations</h2> |
| 187 | <blockquote><ol type="I"> |
| 188 | <li><p> |
| 189 | Fossil does not distinguish between the various HTTP methods (GET, PUT, |
| 190 | DELETE, etc). Fossil figures out what it needs to do purely from the |
| 191 | webpage term of the URI. |
| 192 | <li><p> |
| 193 | Fossil does not distinguish between query parameters that are part of the |
| 194 | URI, application/x-www-form-urlencoded or multipart/form-data encoded |
| 195 | parameter that are part of the POST content, and cookies. Each information |
| 196 | source is seen as a space of key/value pairs which are loaded into an |
| 197 | internal property hash table. The code that runs to generate the reply |
| 198 | can then reference various properties values. |
| 199 | Fossil does not care where the value of each property comes from (POST |
| 200 | content, cookies, or query parameters) only that the property exist |
| 201 | and has a value. |
| 202 | <li><p> |
| 203 | The "[/help?cmd=ui|fossil ui]" and "[/help?cmd=server|fossil server]" commands |
| 204 | are implemented using a simple built-in web server that accepts incoming HTTP |
| 205 | requests, translates each request into a CGI invocation, then creates a |
| 206 | separate child Fossil process to handle each request. In other words, CGI |
| 207 | is used internally to implement "fossil ui/server". |
| 208 | <p> |
| 209 | SCGI is processed using the same built-in web server, just modified |
| 210 | to parse SCGI requests instead of HTTP requests. Each SCGI request is |
| 211 | converted into CGI, then Fossil creates a separate child Fossil |
| 212 | process to handle each CGI request. |
| 213 | </ol> |
| 214 | </blockquote> |
| 215 |