forked from rmyorston/busybox-w32
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-coar-cgi-v11-03-clean.html
2674 lines (2591 loc) · 84.7 KB
/
draft-coar-cgi-v11-03-clean.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Common Gateway Interface - 1.1 *Draft 03* [http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html]
</TITLE>
<!--#if expr="$HTTP_USER_AGENT != /Lynx/" -->
<!--#set var="GUI" value="1" -->
<!--#endif -->
<LINK HREF="mailto:[email protected]" rev="revised">
<LINK REL="STYLESHEET" HREF="cgip-style-rfc.css" TYPE="text/css">
<META name="latexstyle" content="rfc">
<META name="author" content="Ken A L Coar">
<META name="institute" content="IBM Corporation">
<META name="date" content="25 June 1999">
<META name="expires" content="Expires 31 December 1999">
<META name="document" content="INTERNET-DRAFT">
<META name="file" content="<draft-coar-cgi-v11-03.txt>">
<META name="group" content="INTERNET-DRAFT">
<!--
There are a lot of BNF fragments in this document. To make it work
in all possible browsers (including Lynx, which is used to turn it
into text/plain), we handle these by using PREformatted blocks with
a universal internal margin of 2, inside one-level DL blocks.
-->
</HEAD>
<BODY>
<!--
HTML doesn't do paper pagination, so we need to fake it out. Basing
our formatting upon RFC2068, there are four (4) lines of header and
four (4) lines of footer for each page.
<DIV ALIGN="CENTER">
<PRE>
Coar, et al. CGI/1.1 Specification May, 1998
INTERNET-DRAFT Expires 1 December 1998 [Page 2]
</PRE>
</DIV>
-->
<!--
The following weirdness wrt non-breaking spaces is to get Lynx
(which is barely TABLE-aware) to line the left/right justified
text up properly.
-->
<DIV ALIGN="CENTER">
<TABLE WIDTH="100%" CELLPADDING=0 CELLSPACING=0>
<TR VALIGN="TOP">
<TD ALIGN="LEFT">
INTERNET-DRAFT
</TD>
<TD ALIGN="RIGHT">
Ken A L Coar
</TD>
</TR>
<TR VALIGN="TOP">
<TD ALIGN="LEFT">
draft-coar-cgi-v11-03.{html,txt}
</TD>
<TD ALIGN="RIGHT">
IBM Corporation
</TD>
</TR>
<TR VALIGN="TOP">
<TD ALIGN="LEFT">
</TD>
<TD ALIGN="RIGHT">
D.R.T. Robinson
</TD>
</TR>
<TR VALIGN="TOP">
<TD ALIGN="LEFT">
</TD>
<TD ALIGN="RIGHT">
E*TRADE UK Ltd.
</TD>
</TR>
<TR VALIGN="TOP">
<TD ALIGN="LEFT">
</TD>
<TD ALIGN="RIGHT">
25 June 1999
</TD>
</TR>
</TABLE>
</DIV>
<H1 ALIGN="CENTER">
The WWW Common Gateway Interface
<BR>
Version 1.1
</H1>
<!--#include virtual="I-D-statement" -->
<H2>
<A NAME="Abstract">
Abstract
</A>
</H2>
<P>
The Common Gateway Interface (CGI) is a simple interface for running
external programs, software or gateways under an information server
in a platform-independent manner. Currently, the supported information
servers are HTTP servers.
</P>
<P>
The interface has been in use by the World-Wide Web since 1993. This
specification defines the
"current practice" parameters of the
'CGI/1.1' interface developed and documented at the U.S. National
Centre for Supercomputing Applications [NCSA-CGI].
This document also defines the use of the CGI/1.1 interface
on the Unix and AmigaDOS(tm) systems.
</P>
<P>
Discussion of this draft occurs on the CGI-WG mailing list; see the
project Web page at
<SAMP><URL:<A HREF="http://CGI-Spec.Golux.Com/"
>http://CGI-Spec.Golux.Com/</A>></SAMP>
for details on the mailing list and the status of the project.
</P>
<!--#if expr="$GUI" -->
<H2>
Revision History
</H2>
<P>
The revision history of this draft is being maintained using Web-based
GUI notation, such as struck-through characters and colour-coded
sections. The following legend describes how to determine the origin
of a particular revision according to the colour of the text:
</P>
<DL COMPACT>
<DT>Black
</DT>
<DD>Revision 00, released 28 May 1998
</DD>
<DT>Green
</DT>
<DD>Revision 01, released 28 December 1998
<BR>
Major structure change: Section 4, "Request Metadata (Meta-Variables)"
was moved entirely under <A HREF="#7.0">Section 7</A>, "Data Input to the
CGI Script."
Due to the size of this change, it is noted here and the text in its
former location does <EM>not</EM> appear as struckthrough. This has
caused major <A HREF="#6.0">sections 5</A> and following to decrement
by one. Other
large text movements are likewise not marked up. References to RFC
1738 were changed to 2396 (1738's replacement).
</DD>
<DT>Red
</DT>
<DD>Revision 02, released 2 April, 1999
<BR>
Added text to <A HREF="#8.3">section 8.3</A> defining correct handling
of HTTP/1.1
requests using "chunked" Transfer-Encoding. Labelled metavariable
names in <A HREF="#8.0">section 8</A> with the appropriate detail section
numbers.
Clarified allowed usage of <SAMP>Status</SAMP> and
<SAMP>Location</SAMP> response header fields. Included new
Internet-Draft language.
</DD>
<DT>Fuchsia
</DT>
<DD>Revision 03, released 25 June 1999
<BR>
Changed references from "HTTP" to "Protocol-Specific" for the listing of
things like HTTP_ACCEPT. Changed 'entity-body' and 'content-body' to
'message-body.' Added a note that response headers must comply with
requirements of the protocol level in use. Added a lot of stuff about
security (section 11). Clarified a bunch of productions. Pointed out
that zero-length and omitted values are indistinguishable in this
specification. Clarified production describing order of fields in
script response header. Clarified issues surrounding encoding of
data. Acknowledged additional contributors, and changed one of
the authors' addresses.
</DD>
</DL>
<!--#endif -->
<H2>
<A NAME="Contents">
Table of Contents
</A>
</H2>
<DIV ALIGN="CENTER">
<PRE>
1 Introduction..............................................<A
HREF="#1.0"
>TBD</A>
1.1 Purpose................................................<A
HREF="#1.1"
>TBD</A>
1.2 Requirements...........................................<A
HREF="#1.2"
>TBD</A>
1.3 Specifications.........................................<A
HREF="#1.3"
>TBD</A>
1.4 Terminology............................................<A
HREF="#1.4"
>TBD</A>
2 Notational Conventions and Generic Grammar................<A
HREF="#2.0"
>TBD</A>
2.1 Augmented BNF..........................................<A
HREF="#2.1"
>TBD</A>
2.2 Basic Rules............................................<A
HREF="#2.2"
>TBD</A>
3 Protocol Parameters.......................................<A
HREF="#3.0"
>TBD</A>
3.1 URL Encoding...........................................<A
HREF="#3.1"
>TBD</A>
3.2 The Script-URI.........................................<A
HREF="#3.2"
>TBD</A>
4 Invoking the Script.......................................<A
HREF="#4.0"
>TBD</A>
5 The CGI Script Command Line...............................<A
HREF="#5.0"
>TBD</A>
6 Data Input to the CGI Script..............................<A
HREF="#6.0"
>TBD</A>
6.1 Request Metadata (Metavariables).......................<A
HREF="#6.1"
>TBD</A>
6.1.1 AUTH_TYPE...........................................<A
HREF="#6.1.1"
>TBD</A>
6.1.2 CONTENT_LENGTH......................................<A
HREF="#6.1.2"
>TBD</A>
6.1.3 CONTENT_TYPE........................................<A
HREF="#6.1.3"
>TBD</A>
6.1.4 GATEWAY_INTERFACE...................................<A
HREF="#6.1.4"
>TBD</A>
6.1.5 Protocol-Specific Metavariables.....................<A
HREF="#6.1.5"
>TBD</A>
6.1.6 PATH_INFO...........................................<A
HREF="#6.1.6"
>TBD</A>
6.1.7 PATH_TRANSLATED.....................................<A
HREF="#6.1.7"
>TBD</A>
6.1.8 QUERY_STRING........................................<A
HREF="#6.1.8"
>TBD</A>
6.1.9 REMOTE_ADDR.........................................<A
HREF="#6.1.9"
>TBD</A>
6.1.10 REMOTE_HOST........................................<A
HREF="#6.1.10"
>TBD</A>
6.1.11 REMOTE_IDENT.......................................<A
HREF="#6.1.11"
>TBD</A>
6.1.12 REMOTE_USER........................................<A
HREF="#6.1.12"
>TBD</A>
6.1.13 REQUEST_METHOD.....................................<A
HREF="#6.1.13"
>TBD</A>
6.1.14 SCRIPT_NAME........................................<A
HREF="#6.1.14"
>TBD</A>
6.1.15 SERVER_NAME........................................<A
HREF="#6.1.15"
>TBD</A>
6.1.16 SERVER_PORT........................................<A
HREF="#6.1.16"
>TBD</A>
6.1.17 SERVER_PROTOCOL....................................<A
HREF="#6.1.17"
>TBD</A>
6.1.18 SERVER_SOFTWARE....................................<A
HREF="#6.1.18"
>TBD</A>
6.2 Request Message-Bodies................................<A
HREF="#6.2"
>TBD</A>
7 Data Output from the CGI Script...........................<A
HREF="#7.0"
>TBD</A>
7.1 Non-Parsed Header Output...............................<A
HREF="#7.1"
>TBD</A>
7.2 Parsed Header Output...................................<A
HREF="#7.2"
>TBD</A>
7.2.1 CGI header fields...................................<A
HREF="#7.2.1"
>TBD</A>
7.2.1.1 Content-Type.....................................<A
HREF="#7.2.1.1"
>TBD</A>
7.2.1.2 Location.........................................<A
HREF="#7.2.1.2"
>TBD</A>
7.2.1.3 Status...........................................<A
HREF="#7.2.1.3"
>TBD</A>
7.2.1.4 Extension header fields..........................<A
HREF="#7.2.1.3"
>TBD</A>
7.2.2 HTTP header fields..................................<A
HREF="#7.2.2"
>TBD</A>
8 Server Implementation.....................................<A
HREF="#8.0"
>TBD</A>
8.1 Requirements for Servers...............................<A
HREF="#8.1"
>TBD</A>
8.1.1 Script-URI..........................................<A
HREF="#8.1"
>TBD</A>
8.1.2 Request Message-body Handling.......................<A
HREF="#8.1.2"
>TBD</A>
8.1.3 Required Metavariables..............................<A
HREF="#8.1.3"
>TBD</A>
8.1.4 Response Compliance.................................<A
HREF="#8.1.4"
>TBD</A>
8.2 Recommendations for Servers............................<A
HREF="#8.2"
>TBD</A>
8.3 Summary of Metavariables...............................<A
HREF="#8.3"
>TBD</A>
9 Script Implementation.....................................<A
HREF="#9.0"
>TBD</A>
9.1 Requirements for Scripts...............................<A
HREF="#9.1"
>TBD</A>
9.2 Recommendations for Scripts............................<A
HREF="#9.2"
>TBD</A>
10 System Specifications....................................<A
HREF="#10.0"
>TBD</A>
10.1 AmigaDOS..............................................<A
HREF="#10.1"
>TBD</A>
10.2 Unix..................................................<A
HREF="#10.2"
>TBD</A>
11 Security Considerations..................................<A
HREF="#11.0"
>TBD</A>
11.1 Safe Methods..........................................<A
HREF="#11.1"
>TBD</A>
11.2 HTTP Header Fields Containing Sensitive Information...<A
HREF="#11.2"
>TBD</A>
11.3 Script Interference with the Server...................<A
HREF="#11.3"
>TBD</A>
11.4 Data Length and Buffering Considerations..............<A
HREF="#11.4"
>TBD</A>
11.5 Stateless Processing..................................<A
HREF="#11.5"
>TBD</A>
12 Acknowledgments..........................................<A
HREF="#12.0"
>TBD</A>
13 References...............................................<A
HREF="#13.0"
>TBD</A>
14 Authors' Addresses.......................................<A
HREF="#14.0"
>TBD</A>
</PRE>
</DIV>
<H2>
<A NAME="1.0">
1. Introduction
</A>
</H2>
<H3>
<A NAME="1.1">
1.1. Purpose
</A>
</H3>
<P>
Together the HTTP [<A HREF="#[3]">3</A>,<A HREF="#[8]">8</A>] server
and the CGI script are responsible
for servicing a client
request by sending back responses. The client
request comprises a Universal Resource Identifier (URI)
[<A HREF="#[1]">1</A>], a
request method, and various ancillary
information about the request
provided by the transport mechanism.
</P>
<P>
The CGI defines the abstract parameters, known as
metavariables,
which describe the client's
request. Together with a
concrete programmer interface this specifies a platform-independent
interface between the script and the HTTP server.
</P>
<H3>
<A NAME="1.2">
1.2. Requirements
</A>
</H3>
<P>
This specification uses the same words as RFC 1123
[<A HREF="#[5]">5</A>] to define the
significance of each particular requirement. These are:
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<DL>
<DT><EM>MUST</EM>
</DT>
<DD>
<P>
This word or the adjective 'required' means that the item is an
absolute requirement of the specification.
</P>
</DD>
<DT><EM>SHOULD</EM>
</DT>
<DD>
<P>
This word or the adjective 'recommended' means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
</P>
</DD>
<DT><EM>MAY</EM>
</DT>
<DD>
<P>
This word or the adjective 'optional' means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
</P>
</DD>
</DL>
<P>
An implementation is not compliant if it fails to satisfy one or more
of the 'must' requirements for the protocols it implements. An
implementation that satisfies all of the 'must' and all of the
'should' requirements for its features is said to be 'unconditionally
compliant'; one that satisfies all of the 'must' requirements but not
all of the 'should' requirements for its features is said to be
'conditionally compliant.'
</P>
<H3>
<A NAME="1.3">
1.3. Specifications
</A>
</H3>
<P>
Not all of the functions and features of the CGI are defined in the
main part of this specification. The following phrases are used to
describe the features which are not specified:
</P>
<DL>
<DT><EM>system defined</EM>
</DT>
<DD>
<P>
The feature may differ between systems, but must be the same for
different implementations using the same system. A system will
usually identify a class of operating-systems. Some systems are
defined in
<A HREF="#10.0"
>section 10</A> of this document.
New systems may be defined
by new specifications without revision of this document.
</P>
</DD>
<DT><EM>implementation defined</EM>
</DT>
<DD>
<P>
The behaviour of the feature may vary from implementation to
implementation, but a particular implementation must document its
behaviour.
</P>
</DD>
</DL>
<H3>
<A NAME="1.4">
1.4. Terminology
</A>
</H3>
<P>
This specification uses many terms defined in the HTTP/1.1
specification [<A HREF="#[8]">8</A>]; however, the following terms are
used here in a
sense which may not accord with their definitions in that document,
or with their common meaning.
</P>
<DL>
<DT><EM>metavariable</EM>
</DT>
<DD>
<P>
A named parameter that carries information from the server to the
script. It is not necessarily a variable in the operating-system's
environment, although that is the most common implementation.
</P>
</DD>
<DT><EM>script</EM>
</DT>
<DD>
<P>
The software which is invoked by the server <EM>via</EM> this
interface. It
need not be a standalone program, but could be a
dynamically-loaded or shared library, or even a subroutine in the
server. It <EM>may</EM> be a set of statements
interpreted at run-time, as the term 'script' is frequently
understood, but that is not a requirement and within the context
of this specification the term has the broader definition stated.
</P>
</DD>
<DT><EM>server</EM>
</DT>
<DD>
<P>
The application program which invokes the script in order to service
requests.
</P>
</DD>
</DL>
<H2>
<A NAME="2.0">
2. Notational Conventions and Generic Grammar
</A>
</H2>
<H3>
<A NAME="2.1">
2.1. Augmented BNF
</A>
</H3>
<P>
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
used by RFC 822 [<A HREF="#[6]">6</A>]. This augmented BNF contains
the following constructs:
</P>
<DL>
<DT>name = definition
</DT>
<DD>
<P>
The
definition by the equal character ("="). Whitespace is only
significant in that continuation lines of a definition are
indented.
</P>
</DD>
<DT>"literal"
</DT>
<DD>
<P>
Quotation marks (") surround literal text, except for a literal
quotation mark, which is surrounded by angle-brackets ("<" and ">").
Unless stated otherwise, the text is case-sensitive.
</P>
</DD>
<DT>rule1 | rule2
</DT>
<DD>
<P>
Alternative rules are separated by a vertical bar ("|").
</P>
</DD>
<DT>(rule1 rule2 rule3)
</DT>
<DD>
<P>
Elements enclosed in parentheses are treated as a single element.
</P>
</DD>
<DT>*rule
</DT>
<DD>
<P>
A rule preceded by an asterisk ("*") may have zero or more
occurrences. A rule preceded by an integer followed by an asterisk
must occur at least the specified number of times.
</P>
</DD>
<DT>[rule]
</DT>
<DD>
<P>
An element enclosed in square
brackets ("[" and "]") is optional.
</P>
</DD>
</DL>
<H3>
<A NAME="2.2">
2.2. Basic Rules
</A>
</H3>
<P>
The following rules are used throughout this specification to
describe basic parsing constructs.
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
alpha = lowalpha | hialpha
alphanum = alpha | digit
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h"
| "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p"
| "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
| "y" | "z"
hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H"
| "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P"
| "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
| "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"
| "8" | "9"
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a"
| "b" | "c" | "d" | "e" | "f"
escaped = "%" hex hex
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal tab (9)>
NL = CR | LF
LWSP = SP | HT | NL
tspecial = "(" | ")" | "@" | "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "<" | ">" | "{" | "}"
| SP | HT | NL
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *qdtext <"> ) | ( "<" *qatext ">")
qdtext = <any CHAR except <"> and CTLs but including LWSP>
qatext = <any CHAR except "<", ">" and CTLs but
including LWSP>
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
unreserved = alphanum | mark
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" |
"$" | ","
uric = reserved | unreserved | escaped
</PRE>
<P>
Note that newline (NL) need not be a single character, but can be a
character sequence.
</P>
<H2>
<A NAME="3.0">
3. Protocol Parameters
</A>
</H2>
<H3>
<A NAME="3.1">
3.1. URL Encoding
</A>
</H3>
<P>
Some variables and constructs used here are described as being
'URL-encoded'. This encoding is described in section
2 of RFC
2396
[<A HREF="#[4]">4</A>].
</P>
<P>
An alternate "shortcut" encoding for representing the space
character exists and is in common use. Scripts MUST be prepared to
recognise both '+' and '%20' as an encoded space in a
URL-encoded value.
</P>
<P>
Note that some unsafe characters may have different semantics if
they are encoded. The definition of which characters are unsafe
depends on the context.
For example, the following two URLs do not
necessarily refer to the same resource:
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
http://somehost.com/somedir%2Fvalue
http://somehost.com/somedir/value
</PRE>
<P>
See section
2 of RFC
2396 [<A HREF="#[4]">4</A>]
for authoritative treatment of this issue.
</P>
<H3>
<A NAME="3.2">
3.2. The Script-URI
</A>
</H3>
<P>
The 'Script-URI' is defined as the URI of the resource identified
by the metavariables. Often,
this URI will be the same as
the URI requested by the client (the 'Client-URI'); however, it need
not be. Instead, it could be a URI invented by the server, and so it
can only be used in the context of the server and its CGI interface.
</P>
<P>
The Script-URI has the syntax of generic-RL as defined in section 2.1
of RFC 1808 [<A HREF="#[7]">7</A>], with the exception that object
parameters and
fragment identifiers are not permitted:
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
<scheme>://<host><port>/<path>?<query>
</PRE>
<P>
The various components of the
Script-URI
are defined by some of the
metavariables (see
<A HREF="#4.0">section 4</A>
below);
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
script-uri = protocol "://" SERVER_NAME ":" SERVER_PORT enc-script
enc-path-info "?" QUERY_STRING
</PRE>
<P>
where 'protocol' is obtained
from SERVER_PROTOCOL, 'enc-script' is a
URL-encoded version of SCRIPT_NAME and 'enc-path-info' is a
URL-encoded version of PATH_INFO. See
<A HREF="#4.6">section 4.6</A> for more information about the PATH_INFO
metavariable.
</P>
<P>
Note that the scheme and the protocol are <EM>not</EM> identical;
for instance, a resource accessed <EM>via</EM> an SSL mechanism
may have a Client-URI with a scheme of "<SAMP>https</SAMP>"
rather than "<SAMP>http</SAMP>". CGI/1.1 provides no means
for the script to reconstruct this, and therefore
the Script-URI includes the base protocol used.
</P>
<H2>
<A NAME="4.0">
4. Invoking the Script
</A>
</H2>
<P>
The
script is invoked in a system defined manner. Unless specified
otherwise, the file containing the script will be invoked as an
executable program.
</P>
<H2>
<A NAME="5.0">
5. The CGI Script Command Line
</A>
</H2>
<P>
Some systems support a method for supplying an array of strings to
the CGI script. This is only used in the case of an 'indexed' query.
This is identified by a "GET" or "HEAD" HTTP request with a URL
query
string not containing any unencoded "=" characters. For such a
request,
servers SHOULD parse the search string
into words, using the following rules:
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
search-string = search-word *( "+" search-word )
search-word = 1*schar
schar = xunreserved | escaped | xreserved
xunreserved = alpha | digit | xsafe | extra
xsafe = "$" | "-" | "_" | "."
xreserved = ";" | "/" | "?" | ":" | "@" | "&"
</PRE>
<P>
After parsing, each word is URL-decoded, optionally encoded in a
system defined manner,
and then the argument list is set to the list
of words.
</P>
<P>
If the server cannot create any part of the argument list, then the
server SHOULD NOT generate any command line information. For example, the
number of arguments may be greater than operating system or server
limitations permit, or one of the words may not be representable as an
argument.
</P>
<P>
Scripts SHOULD check to see if the QUERY_STRING value contains an
unencoded "=" character, and SHOULD NOT use the command line arguments
if it does.
</P>
<H2>
<A NAME="6.0">
6. Data Input to the CGI Script
</A>
</H2>
<P>
Information about a request comes from two different sources: the
request header, and any associated
message-body.
Servers MUST
make portions of this information available to
scripts.
</P>
<H3>
<A NAME="6.1">
6.1. Request Metadata
(Metavariables)
</A>
</H3>
<P>
Each CGI server
implementation MUST define a mechanism
to pass data about the request from
the server to the script.
The metavariables containing these
data
are accessed by the script in a system
defined manner.
The
representation of the characters in the
metavariables is
system defined.
</P>
<P>
This specification does not distinguish between the representation of
null values and missing ones. Whether null or missing values
(such as a query component of "?" or "", respectively) are represented
by undefined metavariables or by metavariables with values of "" is
implementation-defined.
</P>
<P>
Case is not significant in the
metavariable
names, in that there cannot be two
different variables
whose names differ in case only. Here they are
shown using a canonical representation of capitals plus underscore
("_"). The actual representation of the names is system defined; for
a particular system the representation MAY be defined differently
than this.
</P>
<P>
Metavariable
values MUST be
considered case-sensitive except as noted
otherwise.
</P>
<P>
The canonical
metavariables
defined by this specification are:
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
AUTH_TYPE
CONTENT_LENGTH
CONTENT_TYPE
GATEWAY_INTERFACE
PATH_INFO
PATH_TRANSLATED
QUERY_STRING
REMOTE_ADDR
REMOTE_HOST
REMOTE_IDENT
REMOTE_USER
REQUEST_METHOD
SCRIPT_NAME
SERVER_NAME
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
</PRE>
<P>
Metavariables with names beginning with the protocol name (<EM>e.g.</EM>,
"HTTP_ACCEPT") are also canonical in their description of request header
fields. The number and meaning of these fields may change independently
of this specification. (See also <A HREF="#6.1.5">section 6.1.5</A>.)
</P>
<H4>
<A NAME="6.1.1">
6.1.1. AUTH_TYPE
</A>
</H4>
<P>
This variable is specific to requests made
<EM>via</EM> the
"<CODE>http</CODE>"
scheme.
</P>
<P>
If the Script-URI
required access authentication for external
access, then the server
MUST set
the value of
this variable
from the '<SAMP>auth-scheme</SAMP>' token in
the request's "<SAMP>Authorization</SAMP>" header
field.
Otherwise
it is
set to NULL.
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | token
</PRE>
<P>
HTTP access authentication schemes are described in section 11 of the
HTTP/1.1 specification [<A HREF="#[8]">8</A>]. The auth-scheme is
not case-sensitive.
</P>
<P>
Servers
MUST
provide this metavariable
to scripts if the request
header included an "<SAMP>Authorization</SAMP>" field
that was authenticated.
</P>
<H4>
<A NAME="6.1.2">
6.1.2. CONTENT_LENGTH
</A>
</H4>
<P>
This
metavariable
is set to the
size of the message-body
entity attached to the request, if any, in decimal
number of octets. If no data are attached, then this
metavariable
is either NULL or not
defined. The syntax is
the same as for
the HTTP "<SAMP>Content-Length</SAMP>" header field (section 14.14, HTTP/1.1
specification [<A HREF="#[8]">8</A>]).
</P><!--#if expr="! $GUI" -->
<P></P><!--#endif -->
<PRE>
CONTENT_LENGTH = "" | 1*digit
</PRE>
<P>
Servers MUST provide this metavariable