forked from solid/specification
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathprotocol-20211217.html
1400 lines (1154 loc) · 170 KB
/
protocol-20211217.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>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta charset="utf-8" />
<title>Solid Protocol</title>
<meta content="width=device-width, initial-scale=1" name="viewport" />
<link href="https://www.w3.org/StyleSheets/TR/2021/base.css" media="all" rel="stylesheet" title="W3C-Base" />
<style>
body {
counter-reset:section;
counter-reset:sub-section;
}
em.rfc2119 { color: #900; }
code, samp { color: #c83500; }
pre code, pre samp { color: #000; }
dfn { font-weight:inherit; }
.do.fragment a { border-bottom:0; }
.do.fragment a:hover { background:none; border-bottom:0; }
section figure pre { margin:1em 0; display:block; }
cite .bibref { font-style: normal; }
.tabs nav ul li { margin:0; }
div.issue, div.note, div.warning {
clear: both;
margin: 1em 0;
padding: 1em 1.2em 0.5em;
position: relative;
}
div.issue h3, div.note h3,
div.issue h4, div.note h4,
div.issue h5, div.note h5 {
margin:0;
font-weight:normal;
font-style:normal;
}
div.issue h3 > span, div.note h3 > span,
div.issue h4 > span, div.note h4 > span,
div.issue h5 > span, div.note h5 > span {
text-transform: uppercase;
}
div.issue h3, div.issue h4, div.issue h5 {
color:#ae1e1e;
}
div.note h3, div.note h4, div.note h5 {
color:#178217;
}
figure .example-h {
margin-top:0;
text-align: left;
color:#827017;
}
figure .example-h > span {
text-transform: uppercase;
}
header address a[href] {
float: right;
margin: 1rem 0 0.2rem 0.4rem;
background: transparent none repeat scroll 0 0;
border: medium none;
text-decoration: none;
}
header address img[src*="logos/W3C"] {
background: #1a5e9a none repeat scroll 0 0;
border-color: #1a5e9a;
border-image: none;
border-radius: 0.4rem;
border-style: solid;
border-width: 0.65rem 0.7rem 0.6rem;
color: white;
display: block;
font-weight: bold;
}
main article > h1 {
font-size: 220%;
font-weight:bold;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]) {
counter-increment:section;
counter-reset:sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) {
counter-increment:sub-section;
counter-reset:sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section {
counter-increment:sub-sub-section;
counter-reset:sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]) section:not([id$=references]):not([id=exit-criteria]) section section {
counter-increment:sub-sub-sub-section;
counter-reset:sub-sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):not([id=exit-criteria]):not([id^=table-of-]) > h2:before {
content:counter(section) ".\00a0";
}
section:not([id$=references]):not([id^=change-log]):not([id=exit-criteria]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";
}
#acknowledgements ul { padding: 0; margin:0 }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }
dl[id^="document-"] ul {
padding-left:0;
list-style-type:none;
}
dl [rel~="odrl:action"],
dl [rel~="odrl:action"] li {
display: inline;
}
dl [rel~="odrl:action"] li:after {
content: ",";
}
dl [rel~="odrl:action"] li:last-child:after {
content: "";
}
</style>
</head>
<body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# deo: http://purl.org/spar/deo/ fabio: http://purl.org/spar/fabio/ cito: http://purl.org/spar/cito/ as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# earl: http://www.w3.org/ns/earl# spec: http://www.w3.org/ns/spec# rel: https://www.w3.org/ns/iana/link-relations/relation# odrl: http://www.w3.org/ns/odrl/2/" typeof="schema:CreativeWork prov:Entity as:Article">
<header>
<address>
<a class="logo" href="https://solidproject.org/"><img height="66" width="72" alt="Solid Project" src="https://solidproject.org/TR/solid.svg"/></a>
</address>
</header>
<main>
<article about="" typeof="schema:Article doap:Specification">
<h1 property="schema:name">Solid Protocol</h1>
<h2>Version <span property="doap:revision">0.9.0</span>, 2021-12-17</h2>
<details open="">
<summary>More details about this document</summary>
<dl id="document-identifier">
<dt>This version</dt>
<dd><a href="https://solidproject.org/TR/2021/protocol-20211217" rel="owl:sameAs">https://solidproject.org/TR/2021/protocol-20211217</a></dd>
</dl>
<dl id="document-original">
<dt>Original resource</dt>
<dd><a href="https://solidproject.org/TR/protocol" rel="mem:original">https://solidproject.org/TR/protocol</a></dd>
</dl>
<dl id="document-editors-draft">
<dt>Editor’s draft</dt>
<dd><a href="https://solidproject.org/ED/protocol" rel="rdfs:seeAlso">https://solidproject.org/ED/protocol</a></dd>
</dl>
<dl id="document-timemap">
<dt>TimeMap</dt>
<dd><a href="https://solidproject.org/TR/protocol.timemap" rel="mem:timemap">https://solidproject.org/TR/protocol.timemap</a></dd>
</dl>
<dl id="document-editors">
<dt>Editors</dt>
<dd id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor schema:author"><span about="https://csarven.ca/#i" typeof="schema:Person"><a rel="schema:url" href="https://csarven.ca/"><span about="https://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span></dd>
<dd id="Tim-Berners-Lee"><span about="" rel="schema:editor schema:author"><span about="https://www.w3.org/People/Berners-Lee/card#i" typeof="schema:Person"><a rel="schema:url" href="https://www.w3.org/People/Berners-Lee/"><span about="https://www.w3.org/People/Berners-Lee/card#i" property="schema:name"><span property="schema:givenName">Tim</span> <span property="schema:familyName">Berners-Lee</span></span></a></span></span></dd>
<dd id="Ruben-Verborgh"><span about="" rel="schema:editor schema:author"><span about="https://ruben.verborgh.org/profile/#me" typeof="schema:Person"><a rel="schema:url" href="https://ruben.verborgh.org/"><span about="https://ruben.verborgh.org/profile/#me" property="schema:name"><span property="schema:givenName">Ruben</span> <span property="schema:familyName">Verborgh</span></span></a></span></span></dd>
<dd id="Kjetil-Kjernsmo"><span about="" rel="schema:editor schema:author"><span about="http://www.kjetil.kjernsmo.net/foaf#me" typeof="schema:Person"><a rel="schema:url" href="http://kjetil.kjernsmo.net/"><span about="http://www.kjetil.kjernsmo.net/foaf#me" property="schema:name"><span property="schema:givenName">Kjetil</span> <span property="schema:familyName">Kjernsmo</span></span></a></span></span></dd>
</dl>
<dl id="document-contributors">
<dt>Contributors</dt>
<dd id="Justin-Bingham"><span about="" rel="schema:contributor"><span about="https://justin.bingham.id/#me" typeof="schema:Person"><a rel="schema:url" href="https://justin.bingham.id/"><span about="https://justin.bingham.id/#me" property="schema:name"><span property="schema:givenName">Justin</span> <span property="schema:familyName">Bingham</span></span></a></span></span></dd>
<dd id="Dmitri-Zagidulin"><span about="" rel="schema:contributor"><span about="http://computingjoy.com/" typeof="schema:Person"><a rel="schema:url" href="http://computingjoy.com/"><span about="http://computingjoy.com/" property="schema:name"><span property="schema:givenName">Dmitri</span> <span property="schema:familyName">Zagidulin</span></span></a></span></span></dd>
<dd id="Aaron-Coburn"><span about="" rel="schema:contributor"><span about="https://people.apache.org/~acoburn/#i" typeof="schema:Person"><a rel="schema:url" href="https://people.apache.org/~acoburn/"><span about="https://people.apache.org/~acoburn/#i" property="schema:name"><span property="schema:givenName">Aaron</span> <span property="schema:familyName">Coburn</span></span></a></span></span></dd>
</dl>
<dl id="document-published">
<dt>Published</dt>
<dd><time content="2021-12-17T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-17T00:00:00Z" property="schema:datePublished">2021-12-17</time></dd>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2021-12-17T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-17T00:00:00Z" property="schema:dateModified">2021-12-17</time></dd>
</dl>
<dl id="document-repository">
<dt>Repository</dt>
<dd><a href="https://github.com/solid/specification" rel="doap:repository">GitHub</a></dd>
<dd><a href="https://github.com/solid/specification/issues" rel="doap:bug-database">Issues</a></dd>
</dl>
<dl id="document-language">
<dt>Language</dt>
<dd><span content="en" lang="" property="dcterms:language" xml:lang="">English</span></dd>
</dl>
<dl id="document-license">
<dt>License</dt>
<dd><a href="http://purl.org/NET/rdflicense/MIT1.0" rel="schema:license">MIT License</a></dd>
</dl>
<dl id="document-status">
<dt>Document Status</dt>
<dd prefix="pso: http://purl.org/spar/pso/" rel="pso:holdsStatusInTime" resource="#a4448776-625a-11ec-b335-d7489507d779"><span rel="pso:withStatus" resource="http://purl.org/spar/pso/published" typeof="pso:PublicationStatus">Published</span></dd>
</dl>
<dl id="document-resource-state">
<dt>Resource State</dt>
<dd><span about="" typeof="mem:Memento">Memento</span></dd>
</dl>
<dl id="document-in-reply-to">
<dt>In Reply To</dt>
<dd><a href="https://solidproject.org/origin" rel="as:inReplyTo">Solid Origin</a></dd>
</dl>
<dl id="document-policy">
<dt>Policy</dt>
<dd>
<dl id="document-policy-offer" rel="odrl:hasPolicy" resource="#document-policy-offer" typeof="odrl:Policy">
<dt>Rule</dt>
<dd><a about="#document-policy-offer" href="https://www.w3.org/TR/odrl-vocab/#term-Offer" typeof="odrl:Offer">Offer</a></dd>
<dt>Unique Identifier</dt>
<dd><a href="https://solidproject.org/TR/protocol#document-policy-offer" rel="odrl:uid">https://solidproject.org/TR/protocol#document-policy-offer</a></dd>
<dt>Target</dt>
<dd><a href="https://solidproject.org/TR/protocol" rel="odrl:target">https://solidproject.org/TR/protocol</a></dd>
<dt>Permission</dt>
<dd>
<dl id="document-permission" rel="odrl:permission" resource="#document-permission" typeof="odrl:Permission">
<dt>Assigner</dt>
<dd><a rel="odrl:assigner" href="https://www.w3.org/community/solid/">W3C Solid Community Group</a></dd>
<dt>Action</dt>
<dd>
<ul rel="odrl:action">
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-aggregate" resource="odrl:aggregate">Aggregate</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-archive" resource="odrl:archive">Archive</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-concurrentUse" resource="odrl:concurrentUse">Concurrent Use</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-DerivativeWorks" resource="http://creativecommons.org/ns#DerivativeWorks">Derivative Works</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-derive" resource="odrl:derive">Derive</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-digitize" resource="odrl:digitize">Digitize</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-display" resource="odrl:display">Display</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Distribution" resource="http://creativecommons.org/ns#Distribution">Distribution</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-index" resource="odrl:index">Index</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-inform" resource="odrl:inform">Inform</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-install" resource="odrl:install">Install</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Notice" resource="http://creativecommons.org/ns#Notice">Notice</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-present" resource="odrl:present">Present</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-print" resource="odrl:print">Print</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-read" resource="odrl:read">Read</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-reproduce" resource="odrl:reproduce">Reproduce</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-Reproduction" resource="http://creativecommons.org/ns#Reproduction">Reproduction</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-stream" resource="odrl:stream">Stream</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-synchronize" resource="odrl:synchronize">Synchronize</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-textToSpeech" resource="odrl:textToSpeech">Text-to-speech</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-transform" resource="odrl:transform">Transform</a></li>
<li><a href="https://www.w3.org/TR/odrl-vocab/#term-translate" resource="odrl:translate">Translate</a></li>
</ul>
</dd>
</dl>
</dd>
</dl>
</dd>
</dl>
</details>
<p class="copyright">MIT License. Copyright © 2019–2021 <a href="http://www.w3.org/community/solid/">W3C Solid Community Group</a>.</p>
<div datatype="rdf:HTML" id="content" property="schema:description">
<section id="abstract">
<h2>Abstract</h2>
<div datatype="rdf:HTML" property="schema:abstract">
<p>This document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.</p>
</div>
</section>
<section id="sotd" inlist="" rel="schema:hasPart" resource="#sotd">
<h2 property="schema:name">Status of This Document</h2>
<div property="schema:description" datatype="rdf:HTML">
<p>This section describes the status of this document at the time of its publication.</p>
<p>This document was published by the <a href="https://www.w3.org/community/solid/">Solid Community Group</a> as <em>Version 0.9.0</em>. The sections that have been incorporated have been reviewed following the <a href="https://github.com/solid/process">Solid process</a>. However, the information in this document is still subject to change. You are invited to <a href="https://github.com/solid/specification/issues">contribute</a> any feedback, comments, or questions you might have.</p>
<p>Publication as <em>Version 0.9.0</em> does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership. This document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p>This document was produced by a group operating under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available.</p>
</div>
</section>
<nav id="toc">
<h2 id="table-of-contents">Table of Contents</h2>
<div>
<ol class="toc">
<li class="tocline">
<a class="tocxref" href="#abstract">Abstract</a>
</li>
<li class="tocline">
<a class="tocxref" href="#sotd">Status of This Document</a>
</li>
<li class="tocline">
<a class="tocxref" href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
<ol>
<li><a href="#terminology"><span class="secno">1.1</span> <span class="content">Terminology</span></a></li>
<li><a href="#namespaces"><span class="secno">1.2</span> <span class="content">Namespaces</span></a></li>
<li><a href="#conformance"><span class="secno">1.3</span> <span class="content">Conformance</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#http"><span class="secno">2</span> <span class="content">Hypertext Transfer Protocol</span></a>
</li>
<li class="tocline">
<a class="tocxref" href="#uri"><span class="secno">3</span> <span class="content">Uniform Resource Identifier</span></a>
</li>
<li class="tocline">
<a class="tocxref" href="#resources"><span class="secno">4</span> <span class="content">Resources</span></a>
<ol>
<li><a href="#storage"><span class="secno">4.1</span> <span class="content">Storage</span></a></li>
<li><a href="#resource-containment"><span class="secno">4.2</span> <span class="content">Resource Containment</span></a></li>
<li><a href="#auxiliary-resources"><span class="secno">4.3</span> <span class="content">Auxiliary Resources</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#reading-writing-resources"><span class="secno">5</span> <span class="content">Reading and Writing Resources</span></a>
<ol>
<li><a href="#resource-type-heuristics"><span class="secno">5.1</span> <span class="content">Resource Type Heuristics</span></a></li>
<li><a href="#reading-resources"><span class="secno">5.2</span> <span class="content">Reading Resources</span></a></li>
<li><a href="#writing-resources"><span class="secno">5.3</span> <span class="content">Writing Resources</span></a></li>
<li><a href="#deleting-resources"><span class="secno">5.4</span> <span class="content">Deleting Resources</span></a></li>
<li><a href="#resource-representations"><span class="secno">5.5</span> <span class="content">Resource Representations</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#notifications"><span class="secno">6</span> <span class="content">Notifications</span></a>
</li>
<li class="tocline">
<a class="tocxref" href="#live-update"><span class="secno">7</span> <span class="content">Live Update</span></a>
</li>
<li class="tocline">
<a class="tocxref" href="#cors"><span class="secno">8</span> <span class="content">Cross-Origin Resource Sharing</span></a>
</li>
<li class="tocline">
<a class="tocxref" href="#identity"><span class="secno">9</span> <span class="content">Identity</span></a>
<ol>
<li><a href="#webid"><span class="secno">9.1</span> <span class="content">WebID</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#authentication"><span class="secno">10</span> <span class="content">Authentication</span></a>
<ol>
<li><a href="#solid-oidc"><span class="secno">10.1</span> <span class="content">Solid-OIDC</span></a></li>
<li><a href="#webid-tls"><span class="secno">10.2</span> <span class="content">WebID-TLS</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#authorization"><span class="secno">11</span> <span class="content">Authorization</span></a>
<ol>
<li><a href="#web-access-control"><span class="secno">11.1</span> <span class="content">Web Access Control</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#http-definitions"><span class="secno">12</span> <span class="content">HTTP Definitions</span></a>
<ol>
<li><a href="#http-headers"><span class="secno">12.1</span> <span class="content">HTTP Headers</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#considerations"><span class="secno">13</span> <span class="content">Considerations</span></a>
<ol>
<li><a href="#security-considerations"><span class="secno">13.1</span> <span class="content">Security Considerations</span></a></li>
<li><a href="#privacy-considerations"><span class="secno">13.2</span> <span class="content">Privacy Considerations</span></a></li>
<li><a href="#accessibility-considerations"><span class="secno">13.3</span> <span class="content">Accessibility Considerations</span></a></li>
<li><a href="#internationalization-considerations"><span class="secno">13.4</span> <span class="content">Internationalization Considerations</span></a></li>
<li><a href="#security-privacy-review"><span class="secno">13.5</span> <span class="content">Security and Privacy Review</span></a></li>
<li><a href="#societal-impact-review"><span class="secno">13.6</span> <span class="content">Societal Impact Review</span></a></li>
</ol>
</li>
<li class="tocline">
<a class="tocxref" href="#references"><span class="secno"></span> <span class="content">References</span></a>
<ol>
<li><a href="#normative-references"><span class="secno"></span> <span class="content">Normative References</span></a></li>
<li><a href="#informative-references"><span class="secno"></span> <span class="content">Informative References</span></a></li>
</ol>
</li>
</ol>
</div>
</nav>
<section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">
<h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>The aims of the Solid project are in line with those of the Web itself: empowerment towards <q cite="https://www.w3.org/2001/tag/doc/ethical-web-principles/">an equitable, informed and interconnected society</q>. Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.</p>
<p>The Solid ecosystem encapsulates a set of specifications that are guided by the principles we have adopted and also the priority of our values. We acknowledge that every technical decision has ethical implications both for the end user (short-term) as well as society (long-term). To contribute towards a net positive social benefit, we use the <cite><a href="https://www.w3.org/2001/tag/doc/ethical-web-principles/" rel="cito:citesForInformation">Ethical Web Principles</a></cite> to orient ourselves. The consensus on the technical designs are informed by common use cases, implementation experience, and use.</p>
<p>An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access control policies, and use preferred applications and services to achieve them.</p>
<p>The general architectural principles of Solid specifications are borrowed from the <cite><a href="https://www.w3.org/TR/webarch/" rel="cito:citesForInformation">Architecture of the World Wide Web</a></cite>. The components as described in each specification may evolve independently – according to the principle of orthogonality in order to increase the flexibility and robustness of the Solid ecosystem. With that, the specifications are loosely coupled and indicate which features overlap with those governed by another specification. Extensibility as well as variability also are taken into account in each specification.</p>
<p>The specifications in the ecosystem describe how Solid servers and clients can be interoperable by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, and query interfaces.</p>
<p>The specifications are accompanied with supplemental documents, such as <em>Primers</em> and <em>Best Practices and Guidelines</em> to help implementers to form a well-rounded understanding of the Solid ecosystem as well as ways to improve their implementations.</p>
<p>This specification is for:</p>
<ul>
<li>Resource server developers that want to enable clients to send and retrieve information;</li>
<li>Application developers that want to implement a client to perform operations on resources.</li>
</ul>
<section id="terminology" inlist="" rel="schema:hasPart" resource="#terminology" typeof="skos:ConceptScheme">
<h3 property="schema:name skos:prefLabel">Terminology</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p property="skos:definition">The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.</p>
<span rel="skos:hasTopConcept"><span resource="#data-pod"></span><span resource="#solid-app"></span><span resource="#uniform-resource-identifier"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#resource-metadata"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span>
<dl>
<dt about="#data-pod" property="skos:prefLabel" typeof="skos:Concept"><dfn id="data-pod">data pod</dfn></dt>
<dd about="#data-pod" property="skos:definition">A data pod is a place for storing documents, with mechanisms for controlling who can access what.</dd>
<dt about="#solid-app" property="skos:prefLabel" typeof="skos:Concept"><dfn id="solid-app">Solid app</dfn></dt>
<dd about="#solid-app" property="skos:definition">A Solid app is an application that reads or writes data from one or more <a href="#storage">storages</a>.</dd>
<dt about="#uniform-resource-identifier" property="skos:prefLabel" typeof="skos:Concept"><dfn id="uniform-resource-identifier">URI</dfn></dt>
<dd about="#uniform-resource-identifier" property="skos:definition">A <dfn>Uniform Resource Identifier</dfn> (<abbr title="Uniform Resource Identifier">URI</abbr>) provides the means for identifying resources [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>].</dd>
<dt about="#resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource">resource</dfn></dt>
<dd about="#resource" property="skos:definition">A resource is the target of an HTTP request identified by a URI [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</dd>
<dt about="#container-resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="container-resource">container resource</dfn></dt>
<dd about="#container-resource" property="skos:definition">A container resource is a hierarchical collection of resources that contains other resources, including containers.</dd>
<dt about="#root-container" property="skos:prefLabel" typeof="skos:Concept"><dfn id="root-container">root container</dfn></dt>
<dd about="#root-container" property="skos:definition">A root container is a container resource that is at the highest level of the collection hierarchy.</dd>
<dt about="#resource-metadata" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource-metadata">resource metadata</dfn></dt>
<dd about="#resource-metadata" property="skos:definition">Resource metadata encompasses data about resources described by means of RDF statements [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</dd>
<dt about="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent">agent</dfn></dt>
<dd about="#agent" property="skos:definition">An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>].</dd>
<dt about="#owner" property="skos:prefLabel" typeof="skos:Concept"><dfn id="owner">owner</dfn></dt>
<dd about="#owner" property="skos:definition">An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.</dd>
<dt about="#origin" property="skos:prefLabel" typeof="skos:Concept"><dfn id="origin">origin</dfn></dt>
<dd about="#origin" property="skos:definition">An origin indicates where an HTTP request originates from [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</dd>
<dt about="#read-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="read-operation">read operation</dfn></dt>
<dd about="#read-operation" property="skos:definition">A read operation entails that information about a resource’s existence or its description can be known. [<a href="https://github.com/solid/specification/issues/149#issue-568433265" rel="cito:citesAsSourceDocument">Source</a>]</dd>
<dt about="#write-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="write-operation">write operation</dfn></dt>
<dd about="#write-operation" property="skos:definition">A write operation entails that information about resources can be created or removed. [<a href="https://github.com/solid/specification/issues/126#issuecomment-569920473" rel="cito:citesAsSourceDocument">Source</a>]</dd>
<dt about="#append-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="append-operation">append operation</dfn></dt>
<dd about="#append-operation" property="skos:definition">An append operation entails that information can be added but not removed. [<a href="https://github.com/solid/specification/issues/118#issuecomment-569648485" rel="cito:citesAsSourceDocument">Source</a>]</dd>
</dl>
</div>
</section>
<section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces">
<h3 property="schema:name">Namespaces</h3>
<div datatype="rdf:HTML" property="schema:description">
<table>
<caption>Prefixes and Namespaces</caption>
<thead>
<tr>
<th>Prefix</th>
<th>Namespace</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>rdf</td>
<td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
<td>[<cite><a class="bibref" href="#bib-rdf-schema">rdf-schema</a></cite>]</td>
</tr>
<tr>
<td>ldp</td>
<td>http://www.w3.org/ns/ldp#</td>
<td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
</tr>
<tr>
<td>solid</td>
<td>http://www.w3.org/ns/solid/terms#</td>
<td>Solid Terms</td>
</tr>
<tr>
<td>pim</td>
<td>http://www.w3.org/ns/pim/space#</td>
<td>Workspace Ontology</td>
</tr>
<tr>
<td>acl</td>
<td>http://www.w3.org/ns/auth/acl#</td>
<td>ACL Ontology</td>
</tr>
<tr>
<td>dcterms</td>
<td>http://purl.org/dc/terms/</td>
<td>[<cite><a class="bibref" href="#bib-dc-terms">DC-TERMS</a></cite>]</td>
</tr>
<tr>
<td>stat</td>
<td>http://www.w3.org/ns/posix/stat</td>
<td>POSIX File Status</td>
</tr>
</tbody>
</table>
</div>
</section>
<section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance">
<h3 property="schema:name">Conformance</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>
<p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in <a href="https://tools.ietf.org/html/bcp14">BCP 14</a> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>
</div>
</section>
</div>
</section>
<section id="http" inlist="" rel="schema:hasPart" resource="#http">
<h2 property="schema:name">Hypertext Transfer Protocol</h2>
<div datatype="rdf:HTML" property="schema:description">
<p>Solid clients and servers need to exchange data securely over the Internet, and they do so using the HTTP Web standard. This section describes in detail which parts of HTTP must be implemented by clients and servers.</p>
<section id="http-server" inlist="" rel="schema:hasPart" resource="#http-server">
<h3 property="schema:name">HTTP Server</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-http-11" rel="spec:requirement" resource="#server-http-11"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1 Message Syntax and Routing</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and <cite>HTTP/1.1 Semantics and Content</cite> [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> <span about="" id="server-http-2" rel="spec:requirement" resource="#server-http-2"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>].</span></span></p>
<p><span about="" id="server-tls-https" rel="spec:requirement" resource="#server-tls-https"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> use TLS connections through the <code>https</code> URI scheme in order to secure the communication with clients.</span></span> <span about="" id="server-tls-https-redirect" rel="spec:requirement" resource="#server-tls-https-redirect"><span property="spec:statement">When both <code>http</code> and <code>https</code> URI schemes are supported, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> redirect all <code>http</code> URIs to their <code>https</code> counterparts using a response with a <code>301</code> status code and a <code>Location</code> header.</span></span></p>
<p><span about="" id="server-conditional-requests" rel="spec:requirement" resource="#server-conditional-requests"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1 Conditional Requests</cite> [<cite><a class="bibref" href="#bib-rfc7232">RFC7232</a></cite>].</span></span> <span about="" id="server-caching" rel="spec:requirement" resource="#server-caching"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>].</span></span> <span about="" id="server-range-requests" rel="spec:requirement" resource="#server-range-requests"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/1.1 Range Requests</cite> [<cite><a class="bibref" href="#bib-rfc7233">RFC7233</a></cite>].</span></span></p>
<p><span about="" id="server-authentication" rel="spec:requirement" resource="#server-authentication"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1 Authentication</cite> [<cite><a class="bibref" href="#bib-rfc7235">RFC7235</a></cite>].</span></span> <span about="" id="server-unauthenticated" rel="spec:requirement" resource="#server-unauthenticated"><span property="spec:statement">When a client does not provide valid credentials when requesting a resource that requires it (see <a href="#webid">WebID</a>), <span rel="spec:requirementSubject" resource="spec:Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> send a response with a <code>401</code> status code (unless <code>404</code> is preferred for security reasons).</span></span></p>
<p><span about="" id="server-content-type" rel="spec:requirement" resource="#server-content-type"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> reject <code>PUT</code>, <code>POST</code> and <code>PATCH</code> requests without the <code>Content-Type</code> header with a status code of <code>400</code>.</span></span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
<section id="http-client" inlist="" rel="schema:hasPart" resource="#http-client">
<h3 property="schema:name">HTTP Client</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="client-http-11" rel="spec:requirement" resource="#client-http-11"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1 Message Syntax and Routing</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and <cite>HTTP/1.1 Semantics and Content</cite> [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> <span about="" id="client-http-2" rel="spec:requirement" resource="#client-http-2"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>].</span></span></p>
<p><span about="" id="client-conditional-requests" rel="spec:requirement" resource="#client-conditional-requests"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/1.1 Conditional Requests</cite> [<cite><a class="bibref" href="#bib-rfc7232">RFC7232</a></cite>].</span></span> <span about="" id="client-caching" rel="spec:requirement" resource="#client-caching"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>].</span></span> <span about="" id="client-range-requests" rel="spec:requirement" resource="#client-range-requests"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/1.1 Range Requests</cite> [<cite><a class="bibref" href="#bib-rfc7233">RFC7233</a></cite>].</span></span></p>
<p><span about="" id="client-authentication" rel="spec:requirement" resource="#client-authentication"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1 Authentication</cite> [<cite><a class="bibref" href="#bib-rfc7235">RFC7235</a></cite>] if it needs to access resources requiring authentication (see <a href="#webid">WebID</a>).</span></span> <span about="" id="client-authentication-different-credentials" rel="spec:requirement" resource="#client-authentication-different-credentials"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Client">client</span> receives a response with a <code>403</code> or <code>404</code> status code, the client <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> repeat the request with different credentials.</span></span></p>
<p><span about="" id="client-content-type" rel="spec:requirement" resource="#client-content-type"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <code>Content-Type</code> HTTP header in <code>PUT</code>, <code>POST</code> and <code>PATCH</code> requests [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
</div>
</section>
<section id="uri" inlist="" rel="schema:hasPart" resource="#uri">
<h2 property="schema:name">Uniform Resource Identifier</h2>
<div datatype="rdf:HTML" property="schema:description">
<div class="note" id="storage-owner-uri-ownership" inlist="" rel="schema:hasPart" resource="#storage-owner-uri-ownership">
<h3 property="schema:name"><span>Note</span>: Storage Owner and URI Ownership</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This specification does not describe the relationship between a Solid storage <q>owner</q> and Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#uri-ownership">URI ownership</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>].</p>
</div>
</div>
<section id="uri-slash-semantics" inlist="" rel="schema:hasPart" resource="#uri-slash-semantics">
<h3 property="schema:name">URI Slash Semantics</h3>
<div datatype="rdf:HTML" property="schema:description">
<p id="uri-slashes-hierarchical-identifier">The slash (<code>/</code>) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource. [<a href="https://github.com/solid/specification/issues/35#issuecomment-547949014" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-uri-trailing-slash-distinct" rel="spec:requirement" resource="#server-uri-trailing-slash-distinct"><span property="spec:statement">If two URIs differ only in the trailing slash, and the <span rel="spec:requirementSubject" resource="spec:Server">server</span> has associated a resource with one of them, then the other URI <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> correspond to another resource.</span></span> <span about="" id="server-uri-redirect-differing" rel="spec:requirement" resource="#server-uri-redirect-differing"><span property="spec:statement">Instead, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> respond to requests for the latter URI with a 301 redirect to the former.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567482817" rel="cito:citesAsSourceDocument">Source</a>]. <span about="" id="server-authorization-redirect" rel="spec:requirement" resource="#server-authorization-redirect"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> authorize prior to this optional redirect.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567454889" rel="cito:citesAsSourceDocument">Source</a>].</p>
</div>
</section>
<section id="uri-persistence" inlist="" rel="schema:hasPart" resource="#uri-persistence">
<h3 property="schema:name">URI Persistence</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p>Servers should not re-use URIs, regardless of the mechanism by which resources are created. Certain specific cases exist where URIs may be reinstated when it identifies the same resource, but only when consistent with Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#URI-persistence">URI persistence</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>]. [<a href="https://github.com/solid/specification/issues/46#issuecomment-589619372" rel="cito:citesAsSourceDocument">Source</a>]</p>
<div class="note" id="uri-reuse" inlist="" rel="schema:hasPart" resource="#uri-reuse">
<h4 property="schema:name"><span>Note</span>: URI Reuse</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Servers that wish to disable URI re-use may want to use the <code>410</code> status code.</p>
</div>
</div>
</div>
</section>
</div>
</section>
<section id="resources" inlist="" rel="schema:hasPart" resource="#resources">
<h2 property="schema:name">Resources</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="storage" inlist="" rel="schema:hasPart" resource="#storage">
<h3 property="schema:name">Storage</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-storage" rel="spec:requirement" resource="#server-storage"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> provide one or more storages (<code>pim:Storage</code>) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see <a href="#resource-containment">Resource Containment</a>).</span></span></p>
<p><span about="" id="server-storage-nonoverlapping" rel="spec:requirement" resource="#server-storage-nonoverlapping"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> supports multiple storages, the URIs <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be allocated to non-overlapping space.</span></span></p>
<p><span about="" id="server-link-storage" rel="spec:requirement" resource="#server-link-storage"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> exposing the storage resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise by including the HTTP <code>Link</code> header with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code> when responding to storage’s request URI.</span></span></p>
<p><span about="" id="client-link-storage" rel="spec:requirement" resource="#client-link-storage">Clients can determine a resource is of type storage by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking for the <code>Link</code> header with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</span></p>
<p><span about="" id="client-storage-disovery" rel="spec:requirement" resource="#client-storage-discovery">Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a <code>Link</code> header with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</span></p>
<p><span about="" id="client-rdf-storage" rel="spec:requirement" resource="#client-rdf-storage">Clients can discover a storage by making an HTTP <code>GET</code> request on the target URL to retrieve an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/pim/space#storage</code>. The object of the relation is the storage (<code>pim:Storage</code>).</span></p>
<p>[<a href="https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/153#issuecomment-624630022" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-storage-track-owner" rel="spec:requirement" resource="#server-storage-track-owner"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> keep track of at least one <a href="#owner">owner</a> of a storage in an implementation defined way.</span></span></p>
<p><span about="" id="server-storage-link-owner" rel="spec:requirement" resource="#server-storage-link-owner"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> wants to advertise the owner of a storage, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include the <code>Link</code> header with <code>rel="http://www.w3.org/ns/solid/terms#owner"</code> targeting the URI of the owner in the response of HTTP <code>HEAD</code> or <code>GET</code> requests targeting the root container.</span></span></p>
<div class="note" id="trust-between-owners" inlist="" rel="schema:hasPart" resource="#trust-between-owners">
<h4 property="schema:name"><span>Note</span>: Trust Between Owners</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>When a server supports multiple storages, there must be complete trust between its owners.</p>
</div>
</div>
<p>[<a href="https://github.com/solid/specification/issues/67" rel="cito:citesAsSourceDocument">Source</a>][<a href=" https://github.com/solid/specification/issues/132" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/153" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/197" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
<section id="resource-containment" inlist="" rel="schema:hasPart" resource="#resource-containment">
<h3 property="schema:name">Resource Containment</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.</p>
<p id="server-hierarchical-containment">There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy. [<a href="https://github.com/solid/specification/issues/98#issuecomment-547506617" rel="cito:citesAsSourceDocument">Source</a>]. It follows that all resources are discoverable from a container and that it is not possible to create orphan resources. [<a href="https://github.com/solid/specification/issues/97#issuecomment-547459396" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-basic-container" rel="spec:requirement" resource="#server-basic-container"><span property="spec:statement">The representation and behaviour of containers in Solid corresponds to LDP Basic Container and <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be supported by <span rel="spec:requirementSubject" resource="spec:Server">server</span>.</span></span> [<a href="https://github.com/solid/specification/issues/47#issuecomment-561675764" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p id="server-container-last-modified">Servers can determine the value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on changes to containment triples.</p>
<div class="note" id="" inlist="container-last-modified-comparison" rel="schema:hasPart" resource="#container-last-modified-comparison">
<h4 property="schema:name"><span>Note</span>: Container Last-Modified Comparison</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>The <code>Last-Modified</code> of a container will not change when other parts of the container changes. This is to avoid instant propagation of changes all the way to the root container. As <code>Last-Modified</code> cannot be reliably used to check whether the container representation has changed in any way. In future versions of this specification, this design may be revisited.</p>
</div>
</div>
<section id="contained-resource-metadata" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata">
<h4 property="schema:name">Contained Resource Metadata</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Container descriptions are not limited to containment triples. To further support client navigation and application interaction, servers can include <a href="#resource-metadata">resource metadata</a> about contained resources as part of the container description, as described below.</p>
<p><span about="" id="server-contained-resource-metadata" rel="spec:requirement" resource="#server-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> include <a href="#contained-resource-metadata-statements" rel="rdfs:seeAlso">resource metadata about contained resources</a> as part of the container description, unless that information is inapplicable to the server.</span></span></p>
<p id="contained-resource-metadata-statements" about="#contained-resource-metadata-statements" typeof="skos:Collection"><span property="skos:prefLabel">Contained resource metadata statements</span> include the properties:</p>
<dl about="#contained-resource-metadata-statements" rel="skos:member">
<dt about="#contained-resource-metadata-rdf-type" id="contained-resource-metadata-rdf-type" property="skos:prefLabel"><code>rdf:type</code></dt>
<dd about="#contained-resource-metadata-rdf-type" property="skos:definition">A class whose URI is the expansion of the <em>URI Template</em> [<cite><a class="bibref" href="#bib-rfc6570">RFC6570</a></cite>] <code>http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource</code>, where <code>iana-media-type</code> corresponds to a value from the IANA Media Types [<cite><a class="bibref" href="#bib-iana-media-types">IANA-MEDIA-TYPES</a></cite>].</dd>
<dt about="#contained-resource-metadata-stat-size" id="contained-resource-metadata-stat-size" property="skos:prefLabel"><code>stat:size</code></dt>
<dd about="#contained-resource-metadata-stat-size" property="skos:definition">A non-negative integer giving the size of the resource in bytes.</dd>
<dt about="#contained-resource-metadata-dcterms-modified" id="contained-resource-metadata-dcterms-modified" property="skos:prefLabel"><code>dcterms:modified</code></dt>
<dd about="#contained-resource-metadata-dcterms-modified" property="skos:definition">The date and time when the resource was last modified.</dd>
<dt about="#contained-resource-metadata-stat-mtime" id="contained-resource-metadata-stat-mtime" property="skos:prefLabel"><code>stat:mtime</code></dt>
<dd about="#contained-resource-metadata-stat-mtime" property="skos:definition">The Unix time when the resource was last modified.</dd>
</dl>
<p id="dcterms-modified-corresponds-last-modified">The <code>dcterms:modified</code> value of a contained resource corresponds with the <code>Last-Modified</code> header value of the contained resource. If one were to perform <code>HEAD</code> or <code>GET</code> requests on the URI of the contained resource at the time of the HTTP message’s generation, then a response with the <code>200</code> status code including the <code>Last-Modified</code> header would indicate the same date and time.</p>
<div class="note" id="contained-resource-metadata-considerations" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata-considerations">
<h5 property="schema:name"><span>Note</span>: Contained Resource Metadata Considerations</h5>
<div datatype="rdf:HTML" property="schema:description">
<p>The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.</p>
</div>
</div>
<p>Contained resource metadata is <a href="#server-protect-contained-resource-metadata" rel="cito:discusses">protected by the server</a>.</p>
<p>[<a href="https://github.com/solid/specification/issues/227" rel="cito:citesAsSourceDocument">Source</a>]
[<a href="https://github.com/solid/specification/issues/343" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/352" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
</div>
</section>
<section id="auxiliary-resources" inlist="" rel="schema:hasPart" resource="#auxiliary-resources">
<h3 property="schema:name">Auxiliary Resources</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Solid has the notion of <em>auxiliary resources</em> to provide supplementary information such as descriptive metadata, authorization conditions, data shape constraints, digital rights or provenance record about a given resource (hereafter referred as the <em>subject resource</em>), and affects how resources and others associated with it are processed, served or interpreted.</p>
<p id="auxiliary-resources-management">Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource that they are associated with.</p>
<p id="auxiliary-resources-rdf-document">Auxiliary resources are represented as <em>RDF document</em>s [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>]. HTTP interactions on auxiliary resources are subject to the requirements as per <cite><a href="#reading-writing-resources">Reading and Writing Resources</a></cite>.</p>
<div class="note" id="self-describing-resources" inlist="" rel="schema:hasPart" resource="#self-describing-resources">
<h4 property="schema:name"><span>Note</span>: Self-describing Resources</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Where applicable, to promote <a href="https://www.w3.org/2001/tag/doc/selfDescribingDocuments">self-describing resources</a>, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.</p>
</div>
</div>
<p>This specification defines the following types of auxiliary resources:</p>
<ul>
<li><a href="#auxiliary-resources-web-access-control">Web Access Control</a></li>
<li><a href="#auxiliary-resources-description-resource">Resource Description</a></li>
</ul>
<p><span about="" id="client-link-auxiliary-type" rel="spec:requirement" resource="#client-link-auxiliary-type">Clients can discover auxiliary resources associated with a subject resource by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>
<table>
<thead>
<tr>
<th>Auxiliary Type</th>
<th>Link Relation</th>
<th>Definitions</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#auxiliary-resources-web-access-control">Web Access Control</a></td>
<td><code>acl</code></td>
<td>[<cite><a class="bibref" href="#bib-wac">WAC</a></cite>]</td>
</tr>
<tr>
<td><a href="#auxiliary-resources-description-resource">Description Resource</a></td>
<td><code>describedby</code></td>
<td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
</tr>
</tbody>
<tfoot>
<tr>
<td colspan="3">
<div class="issue">
<p>The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:</p>
<ul>
<li><code>http://www.w3.org/ns/auth/acl#accessControl</code></li>
<li><code>https://www.w3.org/ns/iana/link-relations/relation#acl</code></li>
<li><code>https://www.w3.org/ns/iana/link-relations/relation#describedby</code></li>
<li><code>https://www.w3.org/ns/iana/link-relations/relation#describes</code></li>
</ul>
<p><a href="https://github.com/solid/specification/issues/172">Issue</a></p>
</div>
</td>
</tr>
</tfoot>
</table>
<section id="auxiliary-resources-web-access-control" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-web-access-control">
<h4 property="schema:name">Web Access Control</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>An auxiliary resource of type <em>Web Access Control</em> provides access control description of a subject resource (<a href="#web-access-control">Web Access Control</a>).</p>
</div>
</section>
<section id="auxiliary-resources-description-resource" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-description-resource">
<h4 property="schema:name">Description Resource</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>An auxiliary resource of type <em>Description Resource</em> provides a description of a subject resource ([<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]).</p>
<p><span about="" id="server-description-resource-max" rel="spec:requirement" resource="#server-description-resource-max"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> directly associate more than one description resource to a subject resource.</span></span></p>
<p><span about="" id="server-description-resource-authorization" rel="spec:requirement" resource="#server-description-resource-authorization"><span property="spec:statement">When an HTTP request targets a description resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> apply the authorization rule that is used for the subject resource with which the description resource is associated.</span></span></p>
<p><span about="" id="client-link-describes" rel="spec:requirement" resource="#client-link-describes">Clients can discover resources that are described by description resources by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header with a <code>rel</code> value of <code>describes</code> (inverse of the <code>describedby</code> relation) [<cite><a class="bibref" href="#bib-rfc6892">RFC6892</a></cite>].</span></p>
</div>
</section>
</div>
</section>
</div>
</section>
<section id="reading-writing-resources" inlist="" rel="schema:hasPart" resource="#reading-writing-resources">
<h2 property="schema:name">Reading and Writing Resources</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-method-not-allowed" rel="spec:requirement" resource="#server-method-not-allowed"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code to requests using HTTP methods that are not supported by the target resource.</span></span> [<a href="https://github.com/solid/specification/issues/117" rel="cito:citesAsSourceDocument">Source</a>]</p>
<section id="resource-type-heuristics" inlist="" rel="schema:hasPart" resource="#resource-type-heuristics">
<h3 property="schema:name">Resource Type Heuristics</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>When creating new resources, servers can determine an effective request URI’s type by examining the URI path ending (<a href="#uri-slash-semantics">URI Slash Semantics</a>).</p>
<p><span about="" id="server-put-patch-uri-assignment" rel="spec:requirement" resource="#server-put-patch-uri-assignment"><span property="spec:statement">When a successful <code>PUT</code> or <code>PATCH</code> request creates a resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the effective request URI to assign the URI to that resource.</span></span></p>
<p><span about="" id="server-post-uri-assignment" rel="spec:requirement" resource="#server-post-uri-assignment"><span property="spec:statement">When a successful <code>POST</code> request creates a resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> assign a URI to that resource.</span></span> <span about="" id="server-slug-uri-assignment" rel="spec:requirement" resource="#server-slug-uri-assignment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> allow clients to suggest the URI of a resource created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-rfc5023">RFC5023</a></cite>].</span></span></p>
<div class="note" id="uri-allocation" inlist="" rel="schema:hasPart" resource="#uri-allocation">
<h4 property="schema:name"><span>Note</span>: URI Allocation</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Clients can use <code>PUT</code> and <code>PATCH</code> requests to assign a URI to a resource. Clients can use <code>POST</code> requests to have the server assign a URI to a resource.</p>
</div>
</div>
<p>[<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/pull/263" rel="cito:citesAsSourceDocument">Source</a>].</p>
</div>
</section>
<section id="reading-resources" inlist="" rel="schema:hasPart" resource="#reading-resources">
<h3 property="schema:name">Reading Resources</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-safe-methods" rel="spec:requirement" resource="#server-safe-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support the HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] for clients to read resources or to determine communication options.</span></span> [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When responding to authorized requests:</p>
<p><span about="" id="server-allow-methods" rel="spec:requirement" resource="#server-allow-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate their support for HTTP Methods by responding to HTTP <code>GET</code> and <code>HEAD</code> requests for the target resource with the HTTP Method tokens in the HTTP response header <code>Allow</code>.</span></span></p>
<p><span about="" id="server-accept-headers" rel="spec:requirement" resource="#server-accept-headers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate supported media types in the HTTP <code>Accept-Patch</code> [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>], <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] and <code>Accept-Put</code> [<cite><a href="#accept-put">The Accept-Put Response Header</a></cite>] response headers that correspond to acceptable HTTP methods listed in <code>Allow</code> header value in response to HTTP <code>GET</code> and <code>HEAD</code> requests.</span></span></p>
<p><span about="" id="server-options-asterisk-accept-headers" rel="spec:requirement" resource="#server-options-asterisk-accept-headers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> include the HTTP <code>Accept-Patch</code>, <code>Accept-Post</code> and <code>Accept-Put</code> headers in the response of a <code>OPTIONS *</code> request.</span></span></p>
<p>[<a href="https://github.com/solid/specification/issues/85#issuecomment-575386251" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/43" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
<section id="writing-resources" inlist="" rel="schema:hasPart" resource="#writing-resources">
<h3 property="schema:name">Writing Resources</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-put-patch-intermediate-containers" rel="spec:requirement" resource="#server-put-patch-intermediate-containers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of <code>PUT</code> and <code>PATCH</code> requests.</span></span> [<a href="https://github.com/solid/specification/issues/68#issuecomment-561690124" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-post-container" rel="spec:requirement" resource="#server-post-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> allow creating new resources with a <code>POST</code> request to URI path ending <code>/</code>.</span></span> <span about="" id="server-post-container-create-resource" rel="spec:requirement" resource="#server-post-container-create-resource"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create a resource with URI path ending <code>/{id}</code> in container <code>/</code>.</span></span> <span about="" id="server-post-container-create-container" rel="spec:requirement" resource="#server-post-container-create-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create a container with URI path ending <code>/{id}/</code> in container <code>/</code> for requests including the HTTP <code>Link</code> header with <code>rel="type"</code> targeting a valid LDP container type.</span></span> [<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/190" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-post-target-not-found" rel="spec:requirement" resource="#server-post-target-not-found"><span property="spec:statement">When a <code>POST</code> method request targets a resource without an existing representation, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>404</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/108#issuecomment-549448159" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-put-patch-auxiliary-resource" rel="spec:requirement" resource="#server-put-patch-auxiliary-resource"><span property="spec:statement">When a <code>PUT</code> or <code>PATCH</code> method request targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create or update it.</span></span> <span about="" id="server-post-slug-auxiliary-resource" rel="spec:requirement" resource="#server-post-slug-auxiliary-resource"><span property="spec:statement">When a <code>POST</code> method request with the <code>Slug</code> header targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>403</code> status code and response body describing the error.</span></span> [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-protect-containment" rel="spec:requirement" resource="#server-protect-containment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>PUT</code> or <code>PATCH</code> on a container to update its containment triples; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-protect-contained-resource-metadata" rel="spec:requirement" resource="#server-protect-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update a container’s <a href="#contained-resource-metadata-statements">resource metadata statements</a>; if the server receives such a request, it MUST respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/227#issuecomment-919312592" rel="cito:citesAsSourceDocument">Source</a>]</p>
<div class="note" id="conditional-update" inlist="" rel="schema:hasPart" resource="#conditional-update">
<h4 property="schema:name"><span>Note</span>: Conditional Update</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Clients are encouraged to use the HTTP <code>If-None-Match</code> header with a value of <code>"*"</code> to prevent an unsafe request method (e.g., <code>PUT</code>, <code>PATCH</code>) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [<a href="https://github.com/solid/specification/issues/108#issuecomment-567272797" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/40#issuecomment-566995240" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/292" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</div>
<p><span about="" id="server-etag" rel="spec:requirement" resource="#server-etag"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> use the HTTP <code>ETag</code> header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the <code>If-Match</code> header in their requests.</span></span></p>
</div>
<section id="n3-patch" inlist="" rel="schema:hasPart" resource="#n3-patch">
<h4 property="schema:name">Modifying Resources Using N3 Patches</h4>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-patch-n3-accept" rel="spec:requirement" resource="#server-patch-n3-accept"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept a <code>PATCH</code> request with an <em>N3 Patch</em> body when the target of the request is an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</span></span> <span about="" id="server-patch-n3-advertise" rel="spec:requirement" resource="#server-patch-n3-advertise"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate support of N3 Patch by listing <code>text/n3</code> as a value of the <code>Accept-Patch</code> header [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>] of relevant responses.</span></span> [<a href="https://github.com/solid/specification/issues/125#issuecomment-959518598" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>An <em>N3 Patch</em> is a document in the <em>Notation3 (N3)</em> format [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>], identified by the media type <code>text/n3</code>, conforming to the following constraints:</p>
<ul>
<li id="server-patch-n3-patches" rel="spec:requirement" resource="#server-patch-n3-patches"><span property="spec:statement">A patch document <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain one or more patch resources.</span></li>
<li id="server-patch-n3-patch-identifier" rel="spec:requirement" resource="#server-patch-n3-patch-identifier"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be identified by a URI or blank node, which we refer to as <code>?patch</code> in the remainder of this section.</span></li>
<li id="server-patch-n3-type" rel="spec:requirement" resource="#server-patch-n3-type">A patch resource <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> contain a triple [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] <code><span property="spec:statement">?patch rdf:type solid:Patch</span></code>.</li>
<li id="server-patch-n3-deletes" rel="spec:requirement" resource="#server-patch-n3-deletes"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:deletes ?deletions</code>.</span></li>
<li id="server-patch-n3-inserts" rel="spec:requirement" resource="#server-patch-n3-inserts">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:inserts ?insertions</code>.</li>
<li id="server-patch-n3-where" rel="spec:requirement" resource="#server-patch-n3-where"><span property="spec:statement">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain at most one triple of the form <code>?patch solid:where ?conditions</code>.</span></li>
<li id="server-patch-n3-formulae" rel="spec:requirement" resource="#server-patch-n3-formulae"><span property="spec:statement">When present, <code>?deletions</code>, <code>?insertions</code>, and <code>?conditions</code> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be non-nested <em>cited formulae</em> [<cite><a class="bibref" href="#bib-notation3">N3</a></cite>] consisting only of triples and/or triple patterns [<cite><a class="bibref" href="#bib-sparql11-query">SPARQL11-QUERY</a></cite>]. When not present, they are presumed to be the empty formula <code>{}</code>.</span></li>
</ul>
<p id="server-patch-n3-default" rel="schema:hasPart" resource="#server-patch-n3-default"><span property="schema:description">While other specifications might provide a structure and interpretation for a wider class of N3 Patch documents, the present specification only governs the application of N3 Patch documents that additionally adhere to the following constraints:</span></p>
<ul about="#server-patch-n3-default">
<li id="server-patch-n3-single" rel="spec:requirement" resource="#server-patch-n3-single"><span property="spec:statement">The patch document <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain exactly one patch resource, identified by one or more of the triple patterns described above, which all share the same <code>?patch</code> subject.</span></li>
<li id="server-patch-n3-simple-type" rel="spec:requirement" resource="#server-patch-n3-type">A patch resource <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> contain a triple <code><span property="spec:statement">?patch rdf:type solid:InsertDeletePatch</span></code>.</li>
<li id="server-patch-n3-variables" rel="spec:requirement" resource="#server-patch-n3-variables"><span property="spec:statement">The <code>?insertions</code> and <code>?deletions</code> formulae <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> contain variables that do not occur in the <code>?conditions</code> formula.</span></li>
<li id="server-patch-n3-blank-nodes" rel="spec:requirement" resource="#server-patch-n3-blank-nodes"><span property="spec:statement">The <code>?insertions</code> and <code>?deletions</code> formulae <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> contain blank nodes.</span></li>
</ul>
<p><span about="" id="server-patch-n3-invalid" rel="spec:requirement" resource="#server-patch-n3-invalid"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>422</code> status code [<cite><a class="bibref" href="#bib-rfc4918">RFC4918</a></cite>] if a patch document does not satisfy all of the above constraints.</span></span></p>
<p><span about="" id="server-n3-patch-where" rel="spec:requirement" resource="#server-n3-patch-where"><span property="spec:statement">When <code>?conditions</code> is non-empty, <span rel="spec:requirementSubject" resource="spec:Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> treat the request as a <a href="#read-operation">Read operation</a>.</span></span> <span about="" id="server-n3-patch-insert" rel="spec:requirement" resource="#server-n3-patch-insert"><span property="spec:statement">When <code>?insertions</code> is non-empty, <span rel="spec:requirementSubject" resource="spec:Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> (also) treat the request as an <a href="#append-operation">Append operation</a>.</span></span> <span about="" id="server-n3-patch-delete" rel="spec:requirement" resource="#server-n3-patch-delete"><span property="spec:statement">When <code>?deletions</code> is non-empty, <span rel="spec:requirementSubject" resource="spec:Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> treat the request as a <a href="#read-operation">Read</a> and <a href="#write-operation">Write operation</a>.</span></span></p>
<p><span about="" id="server-patch-n3-semantics" rel="spec:requirement" resource="#server-patch-n3-semantics"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> process a patch resource against the target document as follows:</span></span></p>
<ol about="#server-patch-n3-semantics">
<li>Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.</li>
<li>If <code>?conditions</code> is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.</li>
<li>If no such mapping exists, or if multiple mappings exist, the <span id="server-patch-n3-semantics-no-mapping" rel="spec:requirement" resource="#server-patch-n3-semantics-no-mapping"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid-archive/query-panel/issues/3" rel="cito:citesAsSourceDocument">Source</a>]</li>
<li>The resulting variable mapping is propagated to the <code>?deletions</code> and <code>?insertions</code> formulae to obtain two sets of resulting triples.</li>
<li>If the set of triples resulting from <code>?deletions</code> is non-empty and the dataset does not contain <em>all</em> of these triples, the <span id="server-patch-n3-semantics-deletions-non-empty-all-triples" rel="spec:requirement" resource="#server-patch-n3-semantics-deletions-non-empty-all-triples"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid-archive/query-panel/issues/3" rel="cito:citesAsSourceDocument">Source</a>]</li>
<li>The triples resulting from <code>?deletions</code> are to be removed from the RDF dataset.</li>
<li>The triples resulting from <code>?insertions</code> are to be added to the RDF dataset, with each blank node from <code>?insertions</code> resulting in a newly created blank node.</li>
<li>The combination of deletions followed by insertions then forms the new resource state of the RDF document, and the server responds with the appropriate status code.</li>
</ol>
</div>
<figure id="n3-patch-example" class="example listing" rel="schema:hasPart" resource="#n3-patch-example">
<p class="example-h"><span>Example</span>: Applying an N3 patch.</p>
<pre about="#n3-patch-example" property="schema:description" typeof="fabio:Script"><code>@prefix solid: <http://www.w3.org/ns/solid/terms#>.</code>
<code>@prefix ex: <http://www.example.org/terms#>.</code>
<code></code>
<code>_:rename a solid:InsertDeletePatch;</code>
<code> solid:where { ?person ex:familyName "Garcia". };</code>
<code> solid:inserts { ?person ex:givenName "Alex". };</code>
<code> solid:deletes { ?person ex:givenName "Claudia". }.</code></pre>
<figcaption property="schema:name">This N3 Patch instructs to rename <em>Claudia Garcia</em> into <em>Alex Garcia</em>, on the condition that no other Garcia family members are present in the target RDF document.</figcaption>
</figure>
</section>
</section>
<section id="deleting-resources" inlist="" rel="schema:hasPart" resource="#deleting-resources">
<h3 property="schema:name">Deleting Resources</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>Servers MUST support the HTTP <code>DELETE</code> method [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-delete-protect-root-container" rel="spec:requirement" resource="#server-delete-protect-root-container"><span property="spec:statement">When a <code>DELETE</code> request targets storage’s root container or its associated ACL resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code.</span></span> <span about="" id="server-disallow-delete" rel="spec:requirement" resource="#server-disallow-delete"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> exclude the <code>DELETE</code> method in the HTTP response header <code>Allow</code> in response to requests to these resources [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/37#issuecomment-627281466" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-delete-remove-containment" rel="spec:requirement" resource="#server-delete-remove-containment"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also remove the corresponding containment triple.</span></span> [<a href="https://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-delete-remove-auxilary-resource" rel="spec:requirement" resource="#server-delete-remove-auxiliary-resource"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also delete the associated auxiliary resources (see the <a href="#auxiliary-resources">Auxiliary Resources</a> section).</span></span></p>
<p><span about="" id="server-delete-remove-empty-container" rel="spec:requirement" resource="#server-delete-remove-empty-container"><span property="spec:statement">When a <code>DELETE</code> request targets a container, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> delete the container if it contains no resources.</span></span> <span about="" id="server-delete-protect-nonempty-container" rel="spec:requirement" resource="#server-delete-protect-nonempty-container"><span property="spec:statement">If the container contains resources, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>409</code> status code and response body describing the error.</span></span> [<a href="https://github.com/solid/specification/pull/187/files/b7426e95a1613e08195a853a4d0a403b7030f494#r447130915" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><em>This section is non-normative.</em></p>
<p id="server-delete-side-effects">The server might perform additional actions, as described in the normative references like [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. For example, the server could remove membership triples referring to the deleted resource, perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.</p>
<p id="server-delete-get">Subsequent <code>GET</code> requests to the deleted resource usually result in a <code>404</code> or <code>410</code> status code, although HTTP allows others. [<a href="https://github.com/solid/specification/issues/72" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/46" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p class="issue">Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278</p>
</div>
</section>
<section id="resource-representations" inlist="" rel="schema:hasPart" resource="#resource-representations">
<h3 property="schema:name">Resource Representations</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-representation-turtle-jsonld" rel="spec:requirement" resource="#server-representation-turtle-jsonld"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> creates a resource on HTTP <code>PUT</code>, <code>POST</code> or <code>PATCH</code> requests such that the request’s representation data encodes an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] (as determined by the <code>Content-Type</code> header), the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept <code>GET</code> requests on this resource when the value of the <code>Accept</code> header requests a representation in <code>text/turtle</code> or <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-turtle">Turtle</a></cite>] [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/45" rel="cito:citesAsSourceDocument">Source</a>] <a href="https://github.com/solid/specification/issues/69" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/195" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><span about="" id="server-representation-write-redirect" rel="spec:requirement" resource="#server-representation-write-redirect"><span property="spec:statement">When a <code>PUT</code>, <code>POST</code>, <code>PATCH</code> or <code>DELETE</code> method request targets a representation URL that is different than the resource URL, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>307</code> or <code>308</code> status code and <code>Location</code> header specifying the preferred URI reference.</span></span> [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
</div>
</section>
<section id="notifications" inlist="" rel="schema:hasPart" resource="#notifications">
<h2 property="schema:name">Notifications</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-ldn" rel="spec:requirement" resource="#server-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></span></p>
<p><span about="" id="client-ldn" rel="spec:requirement" resource="#client-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></span></p>
</div>
</section>
<section id="live-update" inlist="" rel="schema:hasPart" resource="#live-update">
<h2 property="schema:name">Live Update</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="websockets" inlist="" rel="schema:hasPart" resource="#websockets">
<h3 property="schema:name">WebSockets</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>For real-time collaborative communication between client and server about changes affecting a resource, this Solid Protocol uses the WebSocket API [<cite><a class="bibref" href="#bib-w3c-html">W3C-HTML</a></cite>] and the WebSocket Protocol.</p>
<p><span about="" id="server-websockets-api" rel="spec:requirement" resource="#server-websockets-api"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> implement the <cite><a href="https://github.com/solid/solid-spec/blob/master/api-websockets.md">Solid WebSockets API</a></cite> [<cite><a class="bibref" href="#bib-solid-websockets-api">SOLID-WEBSOCKETS-API</a></cite>].</span></span></p>
<p><span about="" id="client-websockets-api" rel="spec:requirement" resource="#client-websockets-api"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> implement the <cite><a href="https://github.com/solid/solid-spec/blob/master/api-websockets.md">Solid WebSockets API</a></cite> [<cite><a class="bibref" href="#bib-solid-websockets-api">SOLID-WEBSOCKETS-API</a></cite>].</span></span></p>
<p><em>The following is non-normative.</em></p>
<p>The <cite>Solid WebSockets API</cite> (Unofficial Draft) has been the common protocol for many years. That draft does not include an authentication mechanism, and therefore the Protocol will transition to a new design. The new design is currently at <cite><a href="https://solid.github.io/notifications/protocol" rel="cito:citesAsPotentialSolution">Solid Notifications Protocol</a></cite> [<cite><a class="bibref" href="#bib-solid-notifications-protocol">SOLID-NOTIFICATIONS-PROTOCOL</a></cite>]. It is planned to include both security through authentication, and also common formats with other forms of real-time notification in the Solid ecosystem.</p>
<p>Both client and server implementations should provide the existing protocol, and should transition to providing both protocols as the new one becomes available..</p>
<p>The future directions of the protocol include moving from a simple one-bit notification that a resource has changed, requiring the client to reload the resource, to adding <code>PATCH</code> information in the notification so the client can calculate the new state immediately.</p>
</div>
</section>
</div>
</section>
<section id="cors" inlist="" rel="schema:hasPart" resource="#cors">
<h2 property="schema:name">Cross-Origin Resource Sharing</h2>
<div datatype="rdf:HTML" property="schema:description">
<p><a href="#solid-app">Solid apps</a> typically access data from multiple sources. However, Web browsers by default prevent apps that run on one origin from accessing data on other origins. This cross-origin protection is a security mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses a problem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, a Solid app at <code>https://app.example/</code> would be prevented from accessing data on <code>https://guinan.example/</code> or <code>https://darmok.example/</code>, even when Guinan and Darmok have given the user of the app their permission to see some of their data.</p>
<p>For cases where the other origins have their own access protection mechanism — <a href="#authorization">like within Solid</a> — the browser’s built-in cross-origin protection is actually an obstacle rather than a feature. After all, storages already ensure through access control that certain documents can only be accessed by specific people or applications. Preventively blocking apps from different origins thus introduces an unnecessary barrier.</p>
<p>Fortunately, Web servers can indicate to the browser that certain documents do not require cross-origin protection. This mechanism to selectively disable that protection is called <em>Cross-Origin Resource Sharing</em> or <em>CORS</em> [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>]. By responding to browser requests with a specific combination of HTTP headers, servers can indicate which actions are allowed for a given resource. For Solid, the goal is to allow <em>all</em> actions on the CORS level, such that the deeper <a href="#authorization">Authorization</a> layer can exert full control over the app’s allowed permissions. The next section describes how to achieve this through the right HTTP header configuration.</p>
<section id="cors-server" inlist="" rel="schema:hasPart" resource="#cors-server">
<h3 property="schema:name">CORS Server</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><span about="" id="server-cors" rel="spec:requirement" resource="#server-cors"><span property="spec:statement">A <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> implement the CORS protocol [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the server, and the Solid app can read any response and response headers received from the server. If the server wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as <code>401</code>, <code>403</code>, or <code>404</code> [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span></p>
<div class="note" id="cors-protocol-blocking" inlist="" rel="schema:hasPart" resource="#cors-protocol-blocking">
<h4 property="schema:name"><span>Note</span>: CORS Protocol Blocking</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Since the CORS protocol is part of a Living Standard, it might be changed at any point, which might necessitate changes to server implementations for continued prevention of undesired blocking. A <a href="https://github.com/whatwg/fetch/issues/878">proposal</a> to mitigate this has been suggested.</p>
</div>
</div>
<p>Concretely, <span about="" id="server-cors-access-control-headers" rel="spec:requirement" resource="#server-cors-access-control-headers"><span property="spec:statement">whenever a <span rel="spec:requirementSubject" resource="spec:Server">server</span> receives an HTTP request containing a valid <code>Origin</code> header [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>], the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the appropriate <code>Access-Control-*</code> headers as specified in the CORS protocol [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>].</span></span> In particular, <span about="" id="server-cors-acao-vary" rel="spec:requirement" resource="#server-cors-acao-vary"><span property="spec:statement">the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> set the <code>Access-Control-Allow-Origin</code> header to the valid <code>Origin</code> value from the request and list <code>Origin</code> in the <code>Vary</code> header value.</span></span> <span about="" id="server-cors-aceh" rel="spec:requirement" resource="#server-cors-aceh"><span property="spec:statement">The <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> make all used response headers readable for the Solid app through <code>Access-Control-Expose-Headers</code> (with the possible exception of the <code>Access-Control-*</code> headers themselves).</span></span> <span about="" id="server-cors-options" rel="spec:requirement" resource="#server-cors-options"><span property="spec:statement">A <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also support the HTTP <code>OPTIONS</code> method [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] such that it can respond appropriately to CORS preflight requests.</span></span></p>
<p>Careful attention is warranted, especially because of the many edge cases. For instance, <span about="" id="server-cors-enumerate" rel="spec:requirement" resource="#server-cors-enumerate"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> explicitly enumerate all used response headers under <code>Access-Control-Expose-Headers</code> rather than resorting to <code>*</code>, which does not cover all cases (such as credentials mode set to <code>include</code>).</span></span> <span about="" id="server-cors-accept-acah" rel="spec:requirement" resource="#server-cors-accept-acah"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> also explicitly list <code>Accept</code> under <code>Access-Control-Allow-Headers</code></span></span>, because values longer than 128 characters (not uncommon for RDF-based Solid apps) would otherwise be blocked, despite shorter <code>Accept</code> headers being allowed without explicit mention.</p>
</div>
</section>
</div>