-
Notifications
You must be signed in to change notification settings - Fork 29
/
concepts.json
8789 lines (7933 loc) · 634 KB
/
concepts.json
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
[
{ "concept" : "http-authentication-scheme",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"name-singular" : "HTTP Authentication Scheme",
"name-plural" : "HTTP Authentication Schemes",
"registry" : "http:\/\/www.iana.org\/assignments\/http-authschemes\/http-authschemes.xhtml#authschemes",
"values" :
[
{ "value" : "Basic",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/Basic",
"details" :
[
{ "description" : "The Basic authentication scheme is based on the model that the client needs to authenticate itself with a user-id and a password for each protection space (\"realm\"). The realm value is a free-form string that can only be compared for equality with other realms on that server.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7617#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7617",
"spec-name" : "RFC 7617" } ] },
{ "value" : "Bearer",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/Bearer",
"details" :
[
{ "description" : "All challenges defined by this specification MUST use the auth-scheme value \"Bearer\". This scheme MUST be followed by one or more auth-param values.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6750#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6750",
"spec-name" : "RFC 6750" } ] },
{ "value" : "Digest",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/Digest",
"details" :
[
{ "description" : "The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value and might indicate that username hashing is supported. A valid response contains an unkeyed digest of the username, the password, the given nonce value, the HTTP method, and the requested URI.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616",
"spec-name" : "RFC 7616" } ] },
{ "value" : "HOBA",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/HOBA",
"details" :
[
{ "description" : "An HTTP server that supports HOBA authentication includes the \"HOBA\" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7486#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7486",
"spec-name" : "RFC 7486" } ] },
{ "value" : "Mutual",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/Mutual",
"details" :
[
{ "description" : "The scheme provides true mutual authentication between an HTTP client and an HTTP server, using just a simple password as a credential.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8120#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8120",
"spec-name" : "RFC 8120" } ] },
{ "value" : "Negotiate",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/Negotiate",
"details" :
[
{ "description" : "Use of Kerberos is wrapped in an HTTP auth-scheme of \"Negotiate\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4559#section-4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4559",
"spec-name" : "RFC 4559" } ] },
{ "value" : "OAuth",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/OAuth",
"details" :
[
{ "description" : "Protocol parameters can be transmitted using the HTTP \"Authorization\" header field as defined by RFC 2617 with the auth-scheme name set to \"OAuth\" (case insensitive). Servers MAY indicate their support for the \"OAuth\" auth-scheme by returning the HTTP \"WWW-Authenticate\" response header field upon client requests for protected resources.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5849#section-3.5.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5849",
"spec-name" : "RFC 5849" } ] },
{ "value" : "SCRAM-SHA-1",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/SCRAM-SHA-1",
"details" :
[
{ "description" : "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. SCRAM-SHA-1 is registered for database compatibility with implementations of RFC 5802 that want to also expose HTTP access to a related service, but it is not recommended for new deployments.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7804#section-5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7804",
"spec-name" : "RFC 7804" } ] },
{ "value" : "SCRAM-SHA-256",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/SCRAM-SHA-256",
"details" :
[
{ "description" : "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. For interoperability, all HTTP clients and servers supporting SCRAM MUST implement the SCRAM-SHA-256 authentication mechanism.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7804#section-5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7804",
"spec-name" : "RFC 7804" } ] },
{ "value" : "vapid",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-authentication-scheme\/vapid",
"details" :
[
{ "description" : "This authentication scheme carries a signed JWT, plus the key that signed that JWT. This authentication scheme is for origin-server authentication only. Therefore, this authentication scheme MUST NOT be used with the Proxy-Authenticate or Proxy-Authorization header fields. ",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-webpush-vapid#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-webpush-vapid",
"spec-name" : "Internet Draft ietf-webpush-vapid" } ] } ] },
{ "concept" : "http-cache-directive",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"name-singular" : "HTTP Cache Directive",
"name-plural" : "HTTP Cache Directives",
"registry" : "http:\/\/www.iana.org\/assignments\/http-cache-directives\/http-cache-directives.xhtml",
"values" :
[
{ "value" : "immutable",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/immutable",
"details" :
[
{ "description" : "When present in an HTTP response, the immutable Cache-Control extension indicates that the origin server MUST NOT update the representation of that resource during the freshness lifetime of the response.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8246#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8246",
"spec-name" : "RFC 8246" } ] },
{ "value" : "inv-maxage",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/inv-maxage",
"details" :
[
{ "description" : "When present, the 'inv-maxage' cache-control extension indicates the number of seconds that caches who implement Linked Cache invalidation can consider responses fresh for, provided they are not invalidated.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-nottingham-linked-cache-inv#section-4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/nottingham-linked-cache-inv",
"spec-name" : "Internet Draft nottingham-linked-cache-inv" } ] },
{ "value" : "max-age",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/max-age",
"details" :
[
{ "description" : "The \"max-age\" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a stale response. The \"max-age\" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "max-stale",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/max-stale",
"details" :
[
{ "description" : "The \"max-stale\" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "min-fresh",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/min-fresh",
"details" :
[
{ "description" : "The \"min-fresh\" request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "must-revalidate",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/must-revalidate",
"details" :
[
{ "description" : "The \"must-revalidate\" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "no-cache",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/no-cache",
"details" :
[
{ "description" : "The \"no-cache\" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server. The \"no-cache\" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "no-store",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/no-store",
"details" :
[
{ "description" : "The \"no-store\" directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. \"MUST NOT store\" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "no-transform",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/no-transform",
"details" :
[
{ "description" : "The \"no-transform\" directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.6",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "only-if-cached",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/only-if-cached",
"details" :
[
{ "description" : "The \"only-if-cached\" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.1.7",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "private",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/private",
"details" :
[
{ "description" : "The \"private\" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.2.6",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "proxy-revalidate",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/proxy-revalidate",
"details" :
[
{ "description" : "The \"proxy-revalidate\" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.2.7",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "public",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/public",
"details" :
[
{ "description" : "The \"public\" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.2.5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "s-maxage",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/s-maxage",
"details" :
[
{ "description" : "The \"s-maxage\" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2.2.9",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "stale-if-error",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/stale-if-error",
"details" :
[
{ "description" : "The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5861#section-4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5861",
"spec-name" : "RFC 5861" } ] },
{ "value" : "stale-while-revalidate",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-cache-directive\/stale-while-revalidate",
"details" :
[
{ "description" : "When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5861#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5861",
"spec-name" : "RFC 5861" } ] } ] },
{ "concept" : "http-content-coding",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"name-singular" : "HTTP Content Coding",
"name-plural" : "HTTP Content Codings",
"registry" : "http:\/\/www.iana.org\/assignments\/http-parameters\/http-parameters.xhtml#content-coding",
"values" :
[
{ "value" : "aes128gcm",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/aes128gcm",
"details" :
[
{ "description" : "The \"aes128gcm\" HTTP content coding indicates that a payload has been encrypted using Advanced Encryption Standard (AES) in Galois\/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in RFC 5116. The AEAD_AES_128_GCM algorithm uses a 128 bit content encryption key.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8188#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8188",
"spec-name" : "RFC 8188" } ] },
{ "value" : "br",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/br",
"details" :
[
{ "description" : "This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7932",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7932",
"spec-name" : "RFC 7932" } ] },
{ "value" : "compress",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/compress",
"details" :
[
{ "description" : "The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "deflate",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/deflate",
"details" :
[
{ "description" : "The \"deflate\" coding is a \"zlib\" data format containing a \"deflate\" compressed data stream that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.2.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "exi",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/exi",
"details" :
[
{ "description" : "The content-coding value \"exi\" is registered with the Internet Assigned Numbers Authority (IANA) for use with EXI. Protocols that can identify and negotiate the content coding of XML information independent of its media type, SHOULD use the content coding \"exi\" (case-insensitive) to convey the acceptance or actual use of EXI encoding for XML information.",
"documentation" : "http:\/\/www.w3.org\/TR\/exi\/#contentCoding",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/exi",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/exi" } ] },
{ "value" : "gzip",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/gzip",
"details" :
[
{ "description" : "The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.2.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "identity",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/identity",
"details" :
[
{ "description" : "An \"identity\" token is used as a synonym for \"no encoding\" in order to communicate when no encoding is preferred.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "pack200-gzip",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/pack200-gzip",
"details" :
[
{ "description" : "The Pack200 format can decrease the size of a Java application by a factor of seven to nine, compared with an equivalent JAR containing uncompressed (\"stored\") class files. By contrast, using the zip DEFLATE algorithm integral to JAR and ZIP archives gains a factor of two.",
"documentation" : "http:\/\/www.jcp.org\/en\/jsr\/detail?id=200",
"specification" : "http:\/\/webconcepts.info\/specs\/JCP\/JSR\/200",
"spec-name" : "JSR 200" } ] },
{ "value" : "x-compress",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/x-compress",
"details" :
[
{ "description" : "The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "x-gzip",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-content-coding\/x-gzip",
"details" :
[
{ "description" : "The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.2.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] } ] },
{ "concept" : "http-dig-alg",
"id" : "http:\/\/webconcepts.info\/concepts\/http-dig-alg\/",
"name-singular" : "HTTP Digest Algorithm Value",
"name-plural" : "HTTP Digest Algorithm Values",
"registry" : "https:\/\/www.iana.org\/assignments\/http-dig-alg\/http-dig-alg.xhtml#http-dig-alg-1",
"values" :
[ ] },
{ "concept" : "http-forwarded-parameter",
"id" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/",
"name-singular" : "HTTP Forwarded Parameter",
"name-plural" : "HTTP Forwarded Parameters",
"registry" : "http:\/\/www.iana.org\/assignments\/http-parameters\/http-parameters.xhtml#forwarded",
"values" :
[
{ "value" : "by",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/by",
"details" :
[
{ "description" : "The \"by\" parameter is used to disclose the interface where the request came in to the proxy server.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7239#section-5.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7239",
"spec-name" : "RFC 7239" } ] },
{ "value" : "for",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/for",
"details" :
[
{ "description" : "The \"for\" parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7239#section-5.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7239",
"spec-name" : "RFC 7239" } ] },
{ "value" : "host",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/host",
"details" :
[
{ "description" : "The \"host\" parameter is used to forward the original value of the \"Host\" header field.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7239#section-5.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7239",
"spec-name" : "RFC 7239" } ] },
{ "value" : "proto",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-forwarded-parameter\/proto",
"details" :
[
{ "description" : "The \"proto\" parameter has the value of the used protocol type.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7239#section-5.4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7239",
"spec-name" : "RFC 7239" } ] } ] },
{ "concept" : "http-hash-alg",
"id" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/",
"name-singular" : "Hash Algorithm for HTTP Digest Authentication",
"name-plural" : "Hash Algorithms for HTTP Digest Authentication",
"registry" : "https:\/\/www.iana.org\/assignments\/http-dig-alg\/http-dig-alg.xhtml#hash-alg",
"values" :
[
{ "value" : "MD5",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/MD5",
"details" :
[
{ "description" : "MD5",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-6.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616",
"spec-name" : "RFC 7616" } ] },
{ "value" : "SHA-256",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/SHA-256",
"details" :
[
{ "description" : "SHA-256",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-6.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616",
"spec-name" : "RFC 7616" } ] },
{ "value" : "SHA-512-256",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-hash-alg\/SHA-512-256",
"details" :
[
{ "description" : "SHA-512-256",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-6.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616",
"spec-name" : "RFC 7616" } ] } ] },
{ "concept" : "http-header",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"name-singular" : "HTTP Header Field",
"name-plural" : "HTTP Header Fields",
"registry" : "http:\/\/www.iana.org\/assignments\/message-headers\/message-headers.xhtml",
"values" :
[
{ "value" : "A-IM",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/A-IM",
"details" :
[
{ "description" : "The A-IM request-header field is similar to Accept, but restricts the instance-manipulations that are acceptable in the response. A response may be the result of applying multiple instance-manipulations. When an A-IM request-header field includes one or more delta-coding values, the request MUST contain an If-None-Match header field, listing one or more entity tags from prior responses for the request-URI.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3229#section-10.5.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3229",
"spec-name" : "RFC 3229" } ] },
{ "value" : "ALPN",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/ALPN",
"details" :
[
{ "description" : "Clients include the ALPN header field in an HTTP CONNECT request to indicate the application-layer protocol that a client intends to use within the tunnel, or a set of protocols that might be used within the tunnel.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7639#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7639",
"spec-name" : "RFC 7639" } ] },
{ "value" : "Accept",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept",
"details" :
[
{ "description" : "The \"Accept\" header field can be used by user agents to specify response media types that are acceptable. Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "Accept-Additions",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Additions",
"details" :
[
{ "description" : "In HTTP, the \"Accept\" request-header field is used to specify media types which are acceptable for the response. However, in HTCPCP, the response may result in additional actions on the part of the automated pot. For this reason, HTCPCP adds a new header field, \"Accept-Additions\".",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2324#section-2.2.2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2324",
"spec-name" : "RFC 2324" },
{ "description" : "It has been observed that some users of blended teas have an occasional preference for teas brewed as an emulsion of cane sugar with hints of water. To allow for this circumstance, the Accept-Additions header field defined in the base HTCPCP specification is updated to allow the following options.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7168#section-2.2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7168",
"spec-name" : "RFC 7168" } ] },
{ "value" : "Accept-CH",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-CH",
"details" :
[
{ "description" : "The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-hints#section-3.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-hints",
"spec-name" : "Internet Draft ietf-httpbis-client-hints" } ] },
{ "value" : "Accept-Charset",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Charset",
"details" :
[
{ "description" : "The \"Accept-Charset\" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "Accept-Datetime",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Datetime",
"details" :
[
{ "description" : "The \"Accept-Datetime\" request header is transmitted by a user agent to indicate it wants to access a past state of an Original Resource. To that end, the \"Accept-Datetime\" header is conveyed in an HTTP request issued against a TimeGate for an Original Resource, and its value indicates the datetime of the desired past state of the Original Resource.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7089#section-2.1.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7089",
"spec-name" : "RFC 7089" } ] },
{ "value" : "Accept-Encoding",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Encoding",
"details" :
[
{ "description" : "Section 5.3.4 of RFC 7231 defines \"Accept-Encoding\" as a request header field only. This specification expands that definition to allow \"Accept-Encoding\" as a response header field as well. When present in a response, it indicates what content codings the resource was willing to accept in the associated request. A field value that only contains \"identity\" implies that no content codings were supported.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7694#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7694",
"spec-name" : "RFC 7694" },
{ "description" : "The \"Accept-Encoding\" header field can be used by user agents to indicate what response content-codings are acceptable in the response. An \"identity\" token is used as a synonym for \"no encoding\" in order to communicate when no encoding is preferred.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "Accept-Features",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Features",
"details" :
[
{ "description" : "The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request. Servers can use this information when running a remote variant selection algorithm.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295",
"spec-name" : "RFC 2295" } ] },
{ "value" : "Accept-Indefinite-Ranges",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Indefinite-Ranges",
"details" :
[
{ "description" : "The Accept-Indefinite-Ranges request-header field allows the client to indicate its acceptance of indefinite-sized range requests for a resource.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-combs-http-indeterminate-range#section-2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/combs-http-indeterminate-range",
"spec-name" : "Internet Draft combs-http-indeterminate-range" } ] },
{ "value" : "Accept-Language",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Language",
"details" :
[
{ "description" : "The \"Accept-Language\" header field can be used by user agents to indicate the set of natural languages that are preferred in the response.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "Accept-Patch",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Patch",
"details" :
[
{ "description" : "This specification introduces a new response header Accept-Patch used to specify the patch document formats accepted by the server. Accept-Patch SHOULD appear in the OPTIONS response for any resource that supports the use of the PATCH method. The presence of the Accept-Patch header in response to any method is an implicit indication that PATCH is allowed on the resource identified by the Request-URI.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5789#section-3.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5789",
"spec-name" : "RFC 5789" } ] },
{ "value" : "Accept-Post",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Post",
"details" :
[
{ "description" : "The Accept-Post HTTP header SHOULD appear in the OPTIONS response for any resource that supports the use of the POST method. The presence of the Accept-Post header in response to any method is an implicit indication that POST is allowed on the resource identified by the Request-URI. The presence of a specific document format in this header indicates that that specific format is allowed on POST requests to the resource identified by the Request-URI.",
"documentation" : "http:\/\/www.w3.org\/TR\/ldp\/#header-accept-post",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/ldp",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/ldp" } ] },
{ "value" : "Accept-Profile",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Profile",
"details" :
[
{ "description" : "In order to allow a user agent to inform a server about its preferences regarding profiles for resource representations, the \"Accept-Profile\" HTTP header used. A user agent can specify several profiles and use quality indicators (q-values) to indicate preferences.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-svensson-profiled-representations#section-4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/svensson-profiled-representations",
"spec-name" : "Internet Draft svensson-profiled-representations" } ] },
{ "value" : "Accept-Push-Policy",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Push-Policy",
"details" :
[
{ "description" : "A client can express the desired push policy for a request by sending an \"Accept-Push-Policy\" header field in the request. The header field value contains the push policy that the client expects the server to use when processing the request.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ruellan-http-accept-push-policy#section-3.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ruellan-http-accept-push-policy",
"spec-name" : "Internet Draft ruellan-http-accept-push-policy" } ] },
{ "value" : "Accept-Query",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Query",
"details" :
[
{ "description" : "The \"Accept-Query\" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-safe-method-w-body#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-safe-method-w-body",
"spec-name" : "Internet Draft ietf-httpbis-safe-method-w-body" } ] },
{ "value" : "Accept-Ranges",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Ranges",
"details" :
[
{ "description" : "The \"Accept-Ranges\" header field allows a server to indicate that it supports range requests for the target resource.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7233#section-2.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7233",
"spec-name" : "RFC 7233" } ] },
{ "value" : "Access-Control-Allow-Credentials",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Credentials",
"details" :
[
{ "description" : "The Access-Control-Allow-Credentials header indicates whether the response to request can be exposed when the omit credentials flag is unset. When part of the response to a preflight request it indicates that the actual request can include user credentials.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-credentials-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Allow-Headers",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Headers",
"details" :
[
{ "description" : "The Access-Control-Allow-Headers header indicates, as part of the response to a preflight request, which header field names can be used during the actual request.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-headers-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Allow-Methods",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Methods",
"details" :
[
{ "description" : "The Access-Control-Allow-Methods header indicates, as part of the response to a preflight request, which methods can be used during the actual request.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-methods-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Allow-Origin",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Origin",
"details" :
[
{ "description" : "The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, \"*\", or \"null\" in the response.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-origin-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Expose-Headers",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Expose-Headers",
"details" :
[
{ "description" : "The Access-Control-Expose-Headers header indicates which headers are safe to expose to the API of a CORS API specification.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-expose-headers-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Max-Age",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Max-Age",
"details" :
[
{ "description" : "The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached in a preflight result cache.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-max-age-response-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Request-Headers",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Request-Headers",
"details" :
[
{ "description" : "The Access-Control-Request-Headers header indicates which headers will be used in the actual request as part of the preflight request.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-request-headers-request-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Access-Control-Request-Method",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Request-Method",
"details" :
[
{ "description" : "The Access-Control-Request-Method header indicates which method will be used in the actual request as part of the preflight request.",
"documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-request-method-request-header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] },
{ "value" : "Age",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Age",
"details" :
[
{ "description" : "The \"Age\" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "Allow",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Allow",
"details" :
[
{ "description" : "The \"Allow\" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.4.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231",
"spec-name" : "RFC 7231" } ] },
{ "value" : "Alt-Svc",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alt-Svc",
"details" :
[
{ "description" : "An HTTP(S) origin server can advertise the availability of alternative services to clients by adding an Alt-Svc header field to responses.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7838#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7838",
"spec-name" : "RFC 7838" } ] },
{ "value" : "Alt-Used",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alt-Used",
"details" :
[
{ "description" : "The Alt-Used header field is used in requests to indicate the identity of the alternative service in use, just as the Host header field identifies the host and port of the origin. Alt-Used is intended to allow alternative services to detect loops, differentiate traffic for purposes of load balancing, and generally to ensure that it is possible to identify the intended destination of traffic, since introducing this information after a protocol is in use has proven to be problematic.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7838#section-5",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7838",
"spec-name" : "RFC 7838" } ] },
{ "value" : "Alternates",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alternates",
"details" :
[
{ "description" : "The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource. Responses from resources which do not support transparent content negotiation MAY also use Alternates headers.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295",
"spec-name" : "RFC 2295" } ] },
{ "value" : "Apply-To-Redirect-Ref",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Apply-To-Redirect-Ref",
"details" :
[
{ "description" : "The optional Apply-To-Redirect-Ref header can be used on any request to a redirect reference resource. When it is present and set to \"T\", the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4437#section-12.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4437",
"spec-name" : "RFC 4437" } ] },
{ "value" : "Authentication-Control",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authentication-Control",
"details" :
[
{ "description" : "The Authentication-Control header provides more precise control of the client behavior for Web applications using an HTTP authentication protocol.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8053#section-4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8053",
"spec-name" : "RFC 8053" } ] },
{ "value" : "Authentication-Info",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authentication-Info",
"details" :
[
{ "description" : "HTTP authentication schemes can use the Authentication-Info response header field to communicate information after the client's authentication credentials have been accepted. This information can include a finalization message from the server (e.g., it can contain the server authentication).",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7615#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7615",
"spec-name" : "RFC 7615" } ] },
{ "value" : "Authorization",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authorization",
"details" :
[
{ "description" : "The client is expected to retry the request, passing an Authorization header field line with Digest scheme, which is defined according to the framework above. The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header field for the entity being requested.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-3.4",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616",
"spec-name" : "RFC 7616" },
{ "description" : "Protocol parameters can be transmitted using the HTTP \"Authorization\" header field as defined by RFC 2617 with the auth-scheme name set to \"OAuth\" (case insensitive).",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5849#section-3.5.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5849",
"spec-name" : "RFC 5849" },
{ "description" : "The \"Authorization\" header field allows a user agent to authenticate itself with an origin server - usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7235#section-4.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7235",
"spec-name" : "RFC 7235" } ] },
{ "value" : "C-Ext",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Ext",
"details" :
[
{ "description" : "The C-Ext response header field is used to indicate that all hop-by-hop mandatory extension declarations in the request were fulfilled.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774",
"spec-name" : "RFC 2774" } ] },
{ "value" : "C-Man",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Man",
"details" :
[
{ "description" : "A mandatory extension declaration indicates that the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting an error. Hop-by-hop extension declarations are meaningful only for a single HTTP connection. In HTTP\/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. That is, these header fields are to be included as Connection header field directives.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774",
"spec-name" : "RFC 2774" } ] },
{ "value" : "C-Opt",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Opt",
"details" :
[
{ "description" : "An optional extension declaration indicates that the ultimate recipient of the extension MAY consult and adhere to the rules given by the extension when processing the message, or ignore the extension declaration completely. An agent may not be able to distinguish whether the ultimate recipient does not understand an extension referred to by an optional extension or simply ignores the extension declaration. Hop-by-hop extension declarations are meaningful only for a single HTTP connection. In HTTP\/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. That is, these header fields are to be included as Connection header field directives.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774",
"spec-name" : "RFC 2774" } ] },
{ "value" : "C-PEP",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-PEP",
"details" :
[
{ "description" : "PEP hop-by-hop extension declarations are meaningful only for a single transport-level connection. The C-PEP header field is a hop-by-hop header field and must not be communicated by proxies over further connections.",
"documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743948",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] },
{ "value" : "C-PEP-Info",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-PEP-Info",
"details" :
[
{ "description" : "PEP hop-by-hop policies are meaningful only for a single transport-level connection. The C-PEP-Info header field is a hop-by-hop header field and MUST NOT be communicated by proxies over further connections.",
"documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743954",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] },
{ "value" : "CDN-Cache-Control",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/CDN-Cache-Control",
"details" :
[
{ "description" : "The CDN-Cache-Control response header field is a targeted field that allows origin servers to control the behavior of CDN caches interposed between them and clients separately from other caches that might handle the response. It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a CDN).",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc9213#section-3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/9213",
"spec-name" : "RFC 9213" } ] },
{ "value" : "Cache-Control",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-Control",
"details" :
[
{ "description" : "The \"Cache-Control\" header field is used to specify directives for caches along the request\/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234",
"spec-name" : "RFC 7234" } ] },
{ "value" : "Cache-NT",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-NT",
"details" :
[
{ "description" : "For precisely identifying transferred content independent of the used URL and independent of additional header fields in the context of content negotiation, the Cache-NT header field is used. The new header field carries an SHA-256 value.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-drechsler-httpbis-improved-caching#section-2.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/drechsler-httpbis-improved-caching",
"spec-name" : "Internet Draft drechsler-httpbis-improved-caching" } ] },
{ "value" : "Cache-Status",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-Status",
"details" :
[
{ "description" : "The Cache-Status HTTP response header field indicates how caches have handled that response and its corresponding request.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-cache-header#section-2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-cache-header",
"spec-name" : "Internet Draft ietf-httpbis-cache-header" } ] },
{ "value" : "Cal-Managed-ID",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cal-Managed-ID",
"details" :
[
{ "description" : "The Cal-Managed-ID response header field provides the value of the MANAGED-ID parameter corresponding to a newly added ATTACH property. It MUST be sent only in response to a successful POST request with an action set to attachment-add or attachment-update.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-calext-caldav-attachments#section-5.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-calext-caldav-attachments",
"spec-name" : "Internet Draft ietf-calext-caldav-attachments" } ] },
{ "value" : "Clear-Site-Data",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Clear-Site-Data",
"details" :
[
{ "description" : "The Clear-Site-Data HTTP response header field sends a signal to the user agent that it ought to remove all data of a certain set of types.",
"documentation" : "http:\/\/www.w3.org\/TR\/clear-site-data\/#header",
"specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/clear-site-data",
"spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/clear-site-data" } ] },
{ "value" : "Client-Cert",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Client-Cert",
"details" :
[
{ "description" : "In the context of a TLS terminating reverse proxy deployment, the proxy makes the TLS client certificate available to the backend application with the Client-Cert HTTP header field. This field contains the end-entity certificate used by the client in the TLS handshake.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-cert-field#section-2.2",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-cert-field",
"spec-name" : "Internet Draft ietf-httpbis-client-cert-field" } ] },
{ "value" : "Client-Cert-Chain",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Client-Cert-Chain",
"details" :
[
{ "description" : "In the context of a TLS terminating reverse proxy deployment, the proxy MAY make the certificate chain used for validation of the end-entity certificate available to the backend application with the Client-Cert-Chain HTTP header field. This field contains certificates used by the proxy to validate the certificate used by the client in the TLS handshake. These certificates might or might not have been provided by the client during the TLS handshake.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-cert-field#section-2.3",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-cert-field",
"spec-name" : "Internet Draft ietf-httpbis-client-cert-field" } ] },
{ "value" : "Close",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Close",
"details" :
[
{ "description" : "The header field-name \"Close\" has been registered as \"reserved\", since using that name as an HTTP header field might conflict with the \"close\" connection option of the Connection header field.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-8.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "Connection",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Connection",
"details" :
[
{ "description" : "The \"Connection\" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-6.1",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230",
"spec-name" : "RFC 7230" } ] },
{ "value" : "Content-Base",
"concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/",
"id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Base",
"details" :
[
{ "description" : "The Content-Base entity-header field may be used to specify the base URI for resolving relative URLs within the entity. This header field is described as Base in RFC 1808, which is expected to be revised.",
"documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2068#section-14.11",
"specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2068",