-
Notifications
You must be signed in to change notification settings - Fork 88
/
Copy pathuri-spec-issues.html
5376 lines (4776 loc) · 191 KB
/
uri-spec-issues.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 XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Issues List for the
URI specification revision (RFC 2396 to RFC 3986)</title>
</head>
<body>
<h1>Issues List for the <br>URI specification revision (RFC 2396 to RFC 3986)</h1>
<ul>
<li>RFC 3986: <a href="../rfc/rfc3986.html">rfc3986.html</a>,
<a href="../rfc/rfc3986.txt">rfc3986.txt</a>,
<a href="../rfc/rfc3986.xml">rfc3986.xml</a>
</li>
<li>Example <a href="uri_test.pl">URI reference parser</a> with
<a href="example_uri_refs.txt">input</a> and
<a href="example_uri_refs.out">output</a>
</li>
<li>
<a href="../test/index.html">Test Cases and Implementation Reports</a>
</li>
<li>Published drafts:
<a href="draft-fielding-uri-rfc2396bis-07.txt">07.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-07.html">07.html</a>,
<a href="draft-fielding-uri-rfc2396bis-06.txt">06.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-06.html">06.html</a>,
<a href="draft-fielding-uri-rfc2396bis-05.txt">05.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-05.html">05.html</a>,
<a href="draft-fielding-uri-rfc2396bis-04.txt">04.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-04.html">04.html</a>,
<a href="draft-fielding-uri-rfc2396bis-03.txt">03.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-03.html">03.html</a>,
<a href="draft-fielding-uri-rfc2396bis-02.txt">02.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-02.html">02.html</a>,
<a href="draft-fielding-uri-rfc2396bis-01.txt">01.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-01.html">01.html</a>,
<a href="draft-fielding-uri-rfc2396bis-00.txt">00.txt</a>,
<a href="draft-fielding-uri-rfc2396bis-00.html">00.html</a>
</li>
<li>RFC 2396: <a href="../rfc/rfc2396.html">rfc2396.html</a>,
<a href="../rfc/rfc2396.txt">rfc2396.txt</a>,
<a href="../rfc/rfc2396.xml">rfc2396.xml</a>
</li>
<li>
<a href="http://cvs.apache.org/viewcvs.cgi/ietf-uri/rev-2002/">CVS web view of editor revisions</a>
</li>
<li>
<a href="http://lists.w3.org/Archives/Public/uri/">Archive of
<[email protected]> mailing list discussions</a>
</li>
<li>
<a href="http://www.ietf.org/ID-Checklist.html">IETF Checklist for
Internet Drafts</a>
</li>
</ul>
<table cellpadding="4" width="100%" border="1">
<tr>
<th align="left" bgcolor="#FFFFCC" colspan="4"><font size="+2">Proposed changes for the next draft</font></th>
</tr>
<tr>
<th nowrap="nowrap">name</th><th>title</th><th>type</th><th>status</th>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th align="left" bgcolor="#FFFFCC" colspan="4"><font size="+2">Issues already incorporated within the draft</font></th>
</tr>
<tr>
<th nowrap="nowrap">name</th><th>title</th><th>type</th><th>status</th>
</tr>
<tr>
<td nowrap="nowrap"><a href="#003-relative-query">003-relative-query</a></td><td>inconsistent resolution of query-only relative URI</td><td>relative</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#004-pathless-base">004-pathless-base</a></td><td>resolution algorithm fails for base URI with no path</td><td>relative</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#006-absoluteURIref">006-absoluteURIref</a></td><td>need BNF term for absolute URI with optional fragment</td><td>bnf</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#007-empty-rel_path">007-empty-rel_path</a></td><td>relative URI syntax does not allow empty path</td><td>relative</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#014-empty-opaque_part">014-empty-opaque_part</a></td><td>syntax does not allow "dav:" or "about:" as URI</td><td>opaque_part</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#015-fragment-handling">015-fragment-handling</a></td><td>clarify how URI processor is expected to handle fragment</td><td>fragment</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#016-hostname-toplabel">016-hostname-toplabel</a></td><td>hostname toplabel syntax could be improved</td><td>hostname</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#023-URI-plural">023-URI-plural</a></td><td>URI or URIs for plural</td><td>terminology</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#025-rel_segment">025-rel_segment</a></td><td>rel_segment is defined without distinguishing param</td><td>segment</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#026-ABNF">026-ABNF</a></td><td>replace existing BNF with standard ABNF of RFC 2234</td><td>bnf</td><td nowrap="nowrap">fixed 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#011-IPv6-literal">011-IPv6-literal</a></td><td>integrate IPv6 syntax of RFC 2732</td><td>IPv6</td><td nowrap="nowrap">added 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#012-simplify-IPv6">012-simplify-IPv6</a></td><td>change BNF to incorporate IPv6 better than RFC 2732</td><td>IPv6</td><td nowrap="nowrap">added 00</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#027-ref-HTML">027-ref-HTML</a></td><td>draft 00 contains an obsolete ref to RFC 1866</td><td>references</td><td nowrap="nowrap">fixed 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#028-ref-rfc0952">028-ref-rfc0952</a></td><td>draft 00 normative reference to RFC 952</td><td>references</td><td nowrap="nowrap">fixed 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#030-IPv6-bnf">030-IPv6-bnf</a></td><td>draft 00 errors in IPv6 syntax</td><td>IPv6</td><td nowrap="nowrap">fixed 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#035-scheme-escaping">035-scheme-escaping</a></td><td>%HH escaping should not be scheme-dependent</td><td>characters</td><td nowrap="nowrap">fixed 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#010-gethostbyname">010-gethostbyname</a></td><td>gethostbyname allows much more than hostname BNF</td><td>hostname</td><td nowrap="nowrap">added 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#029-decimal-IP">029-decimal-IP</a></td><td>add security considerations for misleading use of decimal IP</td><td>security</td><td nowrap="nowrap">added 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#037-uri-comparison">037-uri-comparison</a></td><td>define how to compare URIs</td><td>characters</td><td nowrap="nowrap">added 01</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#008-URIvsURIref">008-URIvsURIref</a></td><td>URI versus URI Reference</td><td>terminology</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#017-rdf-fragment">017-rdf-fragment</a></td><td>RDF does not believe in same-document references</td><td>fragment</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#021-relative-examples">021-relative-examples</a></td><td>relative URI examples could be improved</td><td>examples</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#031-query-def">031-query-def</a></td><td>query definition</td><td>query</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#038-qualified">038-qualified</a></td><td>qualified production in hostname is ambiguous</td><td>hostname</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#039-LALR-BNF">039-LALR-BNF</a></td><td>BNF should be more LALR-parser friendly</td><td>bnf</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#042-fragment-when">042-fragment-when</a></td><td>fragment identifiers applied before entire content is retrieved</td><td>fragment</td><td nowrap="nowrap">fixed 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#022-definitions">022-definitions</a></td><td>definitions for operations on URIs</td><td>terminology</td><td nowrap="nowrap">added 02</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#019-URI-URL-URN">019-URI-URL-URN</a></td><td>URI/URL/URN contemporary view</td><td>terminology</td><td nowrap="nowrap">fixed 03</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#033-dot-segments">033-dot-segments</a></td><td>relativising an absolute reference should be invertible</td><td>relative</td><td nowrap="nowrap">fixed 03</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#032-component-examples">032-component-examples</a></td><td>add more examples for generic syntax components</td><td>examples</td><td nowrap="nowrap">added 03</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#036-host-escaping">036-host-escaping</a></td><td>%HH escaping should be allowed on hostname</td><td>characters</td><td nowrap="nowrap">fixed 04</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#040-reg-name">040-reg-name</a></td><td>Remove registry-based name syntax from authority</td><td>authority</td><td nowrap="nowrap">fixed 04</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#041-encoding">041-encoding</a></td><td>Section 2 on encoding causes too much confusion</td><td>characters</td><td nowrap="nowrap">fixed 04</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#018-IPv6-example">018-IPv6-example</a></td><td>RFC 2732 example bug</td><td>IPv6</td><td nowrap="nowrap">added 04</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#044-empty-path">044-empty-path</a></td><td>no path is defined for scheme://ABCD?query</td><td>bnf</td><td nowrap="nowrap">fixed 05</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#024-identity">024-identity</a></td><td>Resource should not be defined as anything that has identity</td><td>terminology</td><td nowrap="nowrap">fixed 06</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#046-lc-edit-relative-URI">046-lc-edit-relative-URI</a></td><td>Rename relative-URI to relative-ref</td><td>editorial</td><td nowrap="nowrap">fixed 07</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#047-lc-edit-canonical">047-lc-edit-canonical</a></td><td>Canonical form seems to be less baked</td><td>editorial</td><td nowrap="nowrap">fixed 07</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#048-lc-edit-iana">048-lc-edit-iana</a></td><td>Add a sentence to IANA considerations</td><td>editorial</td><td nowrap="nowrap">added 07</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th align="left" bgcolor="#FFFFCC" colspan="4"><font size="+2">Issues that will not be incorporated</font></th>
</tr>
<tr>
<th nowrap="nowrap">name</th><th>title</th><th>type</th><th>status</th>
</tr>
<tr>
<td nowrap="nowrap"><a href="#009-nullable-netpath">009-nullable-netpath</a></td><td>syntax for netpath allows empty authority</td><td>netpath</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#013-query-slash">013-query-slash</a></td><td>slash character should be forbidden in query</td><td>query</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#020-utf8-default">020-utf8-default</a></td><td>Defaulting to UTF-8 for unknown encoding</td><td>characters</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#034-identifier">034-identifier</a></td><td>identifier is not just a sequence of characters</td><td>terminology</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#043-same-scheme">043-same-scheme</a></td><td>Should reference resolver ignore scheme if same as base URI?</td><td>relative</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#045-double-slash">045-double-slash</a></td><td>inconsistent handling of .//g relative references</td><td>relative</td><td nowrap="nowrap">closed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#001-file">001-file</a></td><td>file scheme implementations vary on use of authority component</td><td>scheme</td><td nowrap="nowrap">postponed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#002-undefined-schemes">002-undefined-schemes</a></td><td>schemes from RFC 1738 need their own specs</td><td>scheme</td><td nowrap="nowrap">postponed</td>
</tr>
<tr>
<td nowrap="nowrap"><a href="#005-ftp">005-ftp</a></td><td>background on ftp extensions</td><td>scheme</td><td nowrap="nowrap">postponed</td>
</tr>
</table>
<br>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="001-file">001-file</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">file scheme implementations vary on use of authority component</font></th>
</tr>
<tr>
<th bgcolor="lightgrey">postponed</th><th align="left">scheme</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:ccwf_AT_bacchus.com">Charles C. Fu</a>,
15 Jul 1998,
libwww-perl mailing list:
<pre>
[under Windows] it's perfectly legal while on host "foo" to request
file://server/folder/item. On Win32, and on other systems, this
requests the "item" stored in "folder" on the "server" machine. On
Win32, it magically works.
Actually, it is illegal but happens to work with Explorer, does not
work with Netscape under Windows, and may or may not work with other
Windows clients.
In general, the exact details of file URL handling is up to the client
you're using. It's pretty uniform on UNIX systems but is NOT uniform
amongst Windows clients. In particular, Netscape and Explorer handle
file URLs differently under Windows. Here are some examples:
- Netscape correctly handles escapes (like file:///c%3A/ for the
C drive), but Explorer does not.
- Netscape allows file:/// (which is empty), but Explorer does not.
- Explorer allows file:///\\remotehost\share\
and file:////remotehost/share/, but Netscape does not.
I'm sure there are other differences.
[Windows Examples]
file://c:/temp/test.txt => open (FH, "c:/temp/test.txt");
file://c:\temp\test.txt => open (FH, "c:\\temp\\test.txt");
file://localhost/c:/temp/test.txt => open (FH, "c:/temp/test.txt");
file://remotehost/c:/temp/test.txt is not legal
Only the localhost example above is technically legal since host
portions of file URLs must be fully qualified domain names,
'localhost', or empty. The second example is also illegal because a
mandatory '/' must follow the host portion. For the details, see
RFC1738 (Uniform Resource Locators).
The first two examples can be made legal by writing them as
<file:///c:/temp/test.txt>. This happens to work with both
Explorer and Netscape. Again, be warned that it may or may not work
with other Windows clients.
As for UNC paths, I am not aware of a legal way to use them in file
URLs which works with both Netscape and Explorer.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="002-undefined-schemes">002-undefined-schemes</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">schemes from RFC 1738 need their own specs</font></th>
</tr>
<tr>
<th bgcolor="lightgrey">postponed</th><th align="left">scheme</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:LMM_AT_acm.org">Larry Masinter</a>,
09 Sep 1998,
URI-WG mailing list:
<pre>
RFC 2396 obsoletes 1738, which contained:
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service
Of these, 'http' and 'mailto' are covered by their own RFCs now,
but 'ftp', 'news', 'telnet', 'file' should be re-issued. (It's OK
with me if we leave 'gopher', 'wais', and 'prospero' behind.)
'ftp' has never been properly specified, as actually implemented.
'news' should be updated to merge 'news' and 'nttp' according
to current practice, and 'file' needs a proper specification
that handles things like volume names on the windows platform and
suggests that other OS profiles should be developed for local
name mapping.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="003-relative-query">003-relative-query</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">inconsistent resolution of query-only relative URI</font></th>
</tr>
<tr>
<th bgcolor="lightgreen">fixed 00</th><th align="left">relative</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:msabin_AT_milessabin.com">Miles Sabin</a>,
23 Mar 1999,
private mail:
<pre>
I've been working through the relative URI resolution
mechanism in RFC 2396, and I've spotted something which
seems a little odd. The example resolution on p.29 for,
?y
from,
http://a/b/c/d;p?q
is given as,
http://a/b/c/?y
but as far as I can make out, the resolution algorithm
suggests the result ought to be,
http://a/b/c/d;p?y
which is the result that was given in RFC 1808. It's
also the result that both Netscape 4 and IE 4 deliver.
Given that this would be an observable change in
behaviour between the two RFCs, I'm a little surprised
that it wasn't flagged up as such if the change really
was intended ...
Strangely enough, Sun's badly broken java.net.URL class
_does_ give the result specified in 2396, which makes me
suspect that something must be wrong ;-)
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:holtzman_AT_mit.edu">Henry Holtzman</a>,
09 Jul 2002,
private mail:
<pre>
rfc2396 specifies a different browser behavior from rfc1808 in a particular
situation that I believe may be unintentional. IE & Netscape implement the
rfc1808 behavior while Opera implements the rfc2396 behavior. As appendix
G of rfc2396 makes no mention of this change, we would appreciate your
opinion on the matter.
In rfc1808, when the relative URL has no path component, but has a fragment
or a query, the client is supposed to skip step 6 of forming the absolute
URI. In step 6, among other things, the base URI is stripped of all
characters beyond the final "/".
In rfc2396, when the relative URI has no path and has a fragment, it is
specified that processing should be stopped as no new document should be
loaded, but rather navigation within the document is specified. This
change is explained in appendix G.
However, when there is no path component, but there is a query component,
processing continues. The instruction to skip stripping the
post-final-/-characters is gone in rfc2396, which means that the final part
of the base URI is stripped and so the query is not performed on the same
page as was loaded (unless that page's URI ended with a "/". Was this
change between rfc1808 and rfc2396 intended?
The following small php application illustrates the issue. You can run it
at http://www.media.mit.edu/opera/r-url.php. You will note that Opera
(6.03) behaves very differently from Netscape and IE when executing this
page. With IE and Netscape, you can navigate within the application. With
Opera, when you click on the links within the app, you get an index page of
the directory containing the app.
It is my belief that the final characters should *not* be stripped, and
that rfc2396 should be amended to skip the stripping in the case of a
relative URI with only a query component.
<html>
<head>
<title>Example application using empty path relative URLs</title>
</head>
<body>
<h4>Example application using empty path relative URLs</h4>
<?php if ($action=="here") { ?>
Thank you for clicking here!<br><br>
<?php } else if ($action=="there") { ?>
Hey, you weren't supposed to click there!<br><br>
<?php } ?>
Please click <a href="?action=here">here</a>.<br>
Please do not click <a href="?action=there">there</a>.<br>
<br>
Thank you.
</body>
</html>
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
14 Oct 2002,
draft 00:
<pre>
Fixed by rewriting the algorithm as pseudocode and restoring the
original RFC 1808 behavior, with the example changed accordingly.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="004-pathless-base">004-pathless-base</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">resolution algorithm fails for base URI with no path</font></th>
</tr>
<tr>
<th bgcolor="lightgreen">fixed 00</th><th align="left">relative</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:ronald_AT_innovation.ch">Ronald Tschalär</a>,
16 Sep 1999,
private mail:
<pre>
I tried to follow the algorithm in my implementation, but it gives
http://ab :-(
I'm doing:
Input: base: scheme = `http', authority = `a', path = `', query undefined
reference: `b'
Step 1): path = `b'; scheme, authority, query are undefined
Step 2): is a nop
Step 3): scheme = `http'
Step 4): authority = `a'
Step 5): doesn't apply
Step 6): a) gives buffer = `'
b) gives buffer = `b'
c) - g) don't apply
h) gives path = `b'
Step 7): says `http' + `:' + `//' + `a' + `b'
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:amc_AT_cs.berkeley.edu">Adam M. Costello</a>,
21 Apr 2000,
private mail:
<pre>
I think there's a slight bug in the relative URI resolution algorithm in
RFC 2396. Consider:
Base URI = http://foo.com
URI-reference = bar
As far as I can tell, the algorithm yields:
http://foo.combar
This base URI is allowed according to the statement in section 5.2:
Note that only the scheme component is required to be present in the
base URI; the other components may be empty or undefined.
Here's a walk through the algorithm:
step 1: parse reference (no problem)
step 2: query/fragment not inherited from base (no problem)
step 3: scheme inherited from base (no problem)
step 4: authority inherited from base (no problem)
step 5: reference is not absolute (no problem)
step 6a: base URI's path (which is undefined) is copied into buffer
(So the buffer is empty? This may be part of the problem.)
step 6b: "bar" is appended to the buffer (which now contains "bar")
step 6c: remove ./ (no-op)
step 6d: remove trailing . (no-op)
step 6e: remove segment/../ (no-op)
step 6f: remove trailing segment/.. (no-op)
step 6g: check for leading .. (none found)
step 6h: buffer is the new path ("bar")
step 7: result = ""
append "http"
append ":"
append "//"
append "foo.com"
append "bar"
(No check for initial slash, this may be part of the problem.)
return "http://foo.combar"
Presumably the desired absolute URI is http://foo.com/bar. Possible
ways to achieve this include:
1) Alter step 6a to initialize the buffer to "/" if the base URI has no
path.
2) Alter step 7 to insert a slash before any path that does not begin
with a slash (including an empty path).
3) Alter step 7 to insert a slash before any path that begins with a
non-slash (but not before an empty path).
I think proposals 1 and 2 are equivalent, but I haven't considered it
carefully. Proposal 3 gives a different result if the reference is "./"
and the base URI has no path. Proposal 1 looks the cleanest to me.
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
17 Sep 1999,
private mail:
<pre>
I guess step 6a should be
a) All but the last segment of the base URI's path component is
copied to the buffer. In other words, any characters after the
last (right-most) slash character, if any, are excluded.
If the base URI's path component is the empty string, then
a single slash character ("/") is copied to the buffer.
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
14 Sep 2002,
draft 00:
<pre>
Fixed as described above.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="005-ftp">005-ftp</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">background on ftp extensions</font></th>
</tr>
<tr>
<th bgcolor="lightgrey">postponed</th><th align="left">scheme</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:lundberg_AT_wu-ftpd.org">Gregory A Lundberg</a>,
9 Dec 1999,
Apache httpd dev mailing list:
<pre>
If you've already done any server-side commands, you should take a look at
the current specification and consider re-implementing them if you want any
clients to use them.
http://www.wu-ftpd.org/rfc/draft-ietf-ftpext-mlst-09.txt
or
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-09.txt
MIME types are a "Standard Fact". They may or may not be present. If
present, they must conform to the IANA-approved list of type names.
While you're at it, you should notice that language negotiation is, too
some extent, also possible. For this, in addition to the MLST draft, you
should also take a look at RFC 2640, "Internationalization of the File
Transfer Protocol".
The site
http://www.wu-ftpd.org/rfc/
contains a complete list of the FTP RFCs. (Well, nearly complete. I'm
told there's another URL RFC I should include.) If you don't want to
browse the site, or have a local mirror of the RFCs, the complete list of
current RFCs which define the FTP is: 959, 1123, 1579, 1635, 1738, 1808,
2228, 2415, 2428, 2577 and 2640.
The MLST draft just underwent a major change (splitting a feature out for a
separate draft). Other than that, it is fairly mature and should be
progressing to submission to the RFC Editor. The other FTP-related IETF
drafts have, by now, expired and are not expected to progress to
submission.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="006-absoluteURIref">006-absoluteURIref</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">need BNF term for absolute URI with optional fragment</font></th>
</tr>
<tr>
<th bgcolor="lightgreen">fixed 00</th><th align="left">bnf</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:connolly_AT_w3.org">Dan Connolly</a>,
10 Jan 2000,
URI-WG mailing list:
<pre>
I have recently spent a considerable amount of time studying the URI spec
[1] http://www.ietf.org/rfc/rfc2396.txt
and I discovered, somewhat to my surprise, that it
defines the terms "URI reference" and "absolute URI" very precisely,
but
(a) it doesn't define the term "URI", syntactically (!!!)
and
(b) it doesn't give a term for an
absolute-URI-with-optional-fragment-id , i.e. the result of combining
a URI reference with an absolute URI.
This is pretty awkward, since an absolute-URI-with-optional-fragment-id is
really what we meant when we wrote "URI reference" in:
"An XML namespace is a collection of names, identified by a URI
reference"
-- http://www.w3.org/TR/1999/REC-xml-names-19990114/#sec-intro
We used "URI reference" because "absolute URI" excludes fragment identifiers,
and we wanted
http://example.net/#vocab
to be a valid namespace identifier.
But
../xyz/
isn't a namespace identifier, until you combine it with a base absoluteURI.
Another example:
"The locator attribute provides a URI-reference that identifies a remote
resource (or sub-resource)"
-- http://www.w3.org/TR/1999/WD-xlink-19991220/#Local Resources for an
Extended Link
URI-references don't identify remote resources; absoluteURIs do. The
"or sub-resource" makes it clear that the author intends to allow #fragids.
So again, what's needed is a term for absolute-URI-with-optional-fragment-id.
It was called fragmentaddress in RFC1630.
If formal systems float your boat, you can take a look at my formalism
of this stuff in larch:
http://www.w3.org/XML/9711theory/URI
http://www.w3.org/XML/9711theory/URI.html (HTML version with
nasty hacks for math symbols)
http://www.w3.org/XML/9711theory/URI.lsl (original ascii LSL version)
part of
"Specifying Web Architecture with Larch"
http://www.w3.org/XML/9711theory/
which gives pointers explaining larch etc.
I used the term URIwf for absolute-URI-with-optional-fragment-id, and
I used absoluteURI and URI_reference with their rfc2396 meanings.
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
27 Oct 2002,
draft 00:
<pre>
absolute-URI-reference has been added to the section on URI reference
and the ABNF.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="007-empty-rel_path">007-empty-rel_path</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">relative URI syntax does not allow empty path</font></th>
</tr>
<tr>
<th bgcolor="lightgreen">fixed 00</th><th align="left">relative</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:ranschultz_AT_symantec.com">Reese Anschultz</a>,
17 Feb 2000,
private mail:
<pre>
I have an observation regarding section -- "C. Examples of Resolving
Relative URI References" -- within this document.
The document cites that given the well-defined base URI of
http://a/b/c/d;p?q
relative URI
?y
would be resolved as follows:
http://a/b/c/?y
By my interpretation from the BNF, a query can exist as either
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
or
hier_part = ( net_path | abs_path ) [ "?" query ]
Since net_path, abs_path and rel_path must each be a least one character in
length, I believe that the example "?y" is not a valid URI because no
characters proceed the question mark (?).
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:zongaro_AT_ca.ibm.com">Henry Zongaro</a>,
12 Nov 2001,
RFC editor:
<pre>
Appendix C shows an example of a relative URI Reference of "?y" with
respect to the base URI "http://a/b/c/d;p?q". However, according to the
collected syntax that appears in Appendix A, "?y" doesn't appear to be a
valid relative URI reference. The syntactic category URI-reference must
begin with an absoluteURI, a relativeURI or a pound sign. An absoluteURI
begins with a scheme, which cannot begin with a question mark; a
relativeURI begins with a net_path or abs_path, both of which begin with a
slash, or with a rel_path. A rel_path begins with a non-empty
rel_segment, which again cannot begin with a question mark.
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:blilly_AT_erols.com">Bruce Lilly</a>,
16 Jan 2002,
private mail:
<pre>
Section C.2 mentions an empty reference, but the
formal syntax does not provide for that. There are
several possible changes to the formal syntax which
would permit it, e.g. change 1* to * in the
definition of rel_segment, which would permit an
empty rel_path and therefore relativeURI (however,
it would then permit a relativeURI consisting of
"?" query, which might not be desired).
Alternatively, the entire RHS of the relativeURI
definition could be bracketed, i.e. made optional,
which would permit an empty relativeURI without
permitting a lone delimited query.
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
20 Mar 2000,
private mail:
<pre>
I don't even remember making this change, but it was broken
when draft-fielding-uri-syntax-02.txt changed from
rel_path = [ path_segments ] [ "?" query ]
to (in 03):
rel_path = rel_segment [ abs_path ]
rel_segment = 1*( unreserved | escaped |
";" | "@" | "&" | "=" | "+" | "$" | "," )
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
14 Sep 2002,
draft 00:
<pre>
Fixed by making the path optional in the ABNF:
2396:
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
hier_part = ( net_path | abs_path ) [ "?" query ]
draft-00:
relative-URI = [ net-path / abs-path / rel-path ] [ "?" query ]
hier-part = [ net-path / abs-path ] [ "?" query ]
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="008-URIvsURIref">008-URIvsURIref</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">URI versus URI Reference</font></th>
</tr>
<tr>
<th bgcolor="lightgreen">fixed 02</th><th align="left">terminology</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:LMM_AT_acm.org">Larry Masinter</a>,
26 May 2000,
xml-uri mailing list:
<pre>
When we update RFC 2396, I suggest we add an introductory paragraph
explaining that the term "URI" is used ambiguiously in the community
to mean "a URI reference" (corresponding to the URI-reference BNF entity)
or "an absolute URI", and that for this reason, the term "URI" itself
is not defined in the document.
I'd probably fix the Abstract correspondingly, e.g.,
"Informally, a Uniform Resource Identifier is a compact string...."
so that people don't think that the abstract is normative.
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:Jeff.Hodges_AT_kingsmountain.com">Jeff Hodges</a>,
01 Jun 2001,
URI-WG mailing list:
<pre>
It seems to me, in considering points raised in the "Are URI-References bound
to resources?" thread, that some subtleties might be a bit more clear if
changes along the following lines were made to RFC 2396 (i.e. in a future
revision of that doc, if any)..
4. URI References
The term "URI-reference" is used here to denote the common usage of a
^^^^ ^^^^^^^^^^^^^^^ ^
production (delete) s
resource identifier. A URI reference may be absolute or relative,
^
The term "URI reference" is a casual (i.e. natural
language) description for artifacts that are parsable
using the "URI-reference" production.
and may have additional information attached in the form of a
fragment identifier. However, "the URI" that results from such a
reference includes only the absolute URI after the fragment
identifier (if any) is removed and after any relative URI is resolved
to its absolute form. Although it is possible to limit the
discussion of URI syntax and semantics to that of the absolute
result, most usage of URI is within general URI references, and it is
impossible to obtain the URI from such a reference without also
parsing the fragment and resolving the relative form.
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(delete)
add: URI = absoluteURI | relativeURI
add: URI-reference = [ URI ] [ "#" fragment ]
.
.
.
It seems to me that the above suggested re-write of the URI-reference
production, and the additions to the preceding text, would make it easier and
clearer to talk about "URI" artifacts and "URI-reference" artifacts and their
different abstract semantics.
Also, the _term_ "URI reference" isn't defined prior to section 4 (wherein it
is only tangentially defined, imho). Terms that are also used in sections
prior to section 4 whose explicit definition would help the document convey
it's rather abstract notions to the reader are: "document" and "reference".
Explicitly defining how those terms are used and what their semantics are in
the context of URI and URI-reference artifacts are, would be immensely helpful
to readers.
</pre>
</td>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:timbl_AT_w3.org">Tim Berners-Lee</a>,
23 Jan 2003,
URI-WG mailing list:
<pre>
I would very much like us to take the opportunity to clean up the terminology
on the URI spec which has confused people. It is my considered opinion that
this would be far preferable:
URI - the actual identifier string, with or without a #fragid.
URI reference - a string used in a language to specify a URI, for which
relative form may be used where a base exists. ((This is not the only way of
specifying the value of a URI - one can use various
character sets, namespace prefixes, etc))
</pre>
</td>
</tr>
<tr>
<td colspan="2">action:
<a href="mailto:fielding_AT_apache.org">Roy T. Fielding</a>,
23 May 2003,
draft 02:
<pre>
An ABNF production for URI has been introduced to correspond to the
common usage of the term: an absolute URI with optional fragment.
The fragment identifier has been moved back into the section on
generic syntax components and within the URI and relative-URI productions,
though it remains excluded from absolute-URI. The entire text of the
specification has been revised accordingly.
</pre>
</td>
</tr>
</table>
<br>
<table cellpadding="4" width="100%" border="1">
<tr>
<th bgcolor="#FFFFCC"><font size="+2"><a name="009-nullable-netpath">009-nullable-netpath</a></font></th><th align="left" bgcolor="#FFFFCC"><font size="+1">syntax for netpath allows empty authority</font></th>
</tr>
<tr>
<th bgcolor="lightgrey">closed</th><th align="left">netpath</th>
</tr>
<tr>
<td colspan="2">report:
<a href="mailto:kohsuke.kawaguchi_AT_eng.sun.com">Kohsuke Kawaguchi</a>,
15 Mar 2001,
private mail:
<pre>
I found that according to BNF of RFC 2396 "URI Generic Syntax", the
following string is accepted as a valid URI.
"http://12345.678/"
I assumed this should be rejected because substring "12345.678" does not
match hostname production of BNF.
However, actually this string is accepted by the following derivation.
absoluteURI
- scheme ":" hier_part
- "http" ":" abs_path
- "http:" "/" path_segments
- "http:/" segment "/" segment "/"
- "http:/" *pchar "/" *pchar "/"
- "http:/" "/" "12345.678" /"
- "http://12345.678/"
As you see, the fact that segment is nullable makes net_path
production meaningless.
Is this the intention of authors? Or should it be considered as a bug in
BNF? If so, is it appropriate to fix this bug by changing segment as
follows?
segment = 1*pchar *( ";" param )
</pre>
</td>