From 88d8b70cf6571651efd4cac11bf3b1e2848e3489 Mon Sep 17 00:00:00 2001 From: Andres Rey Date: Wed, 24 Oct 2018 19:42:20 +0100 Subject: Update test expectations --- test/test-pages/ietf-1/expected.html | 191 +++++++++++++++++++---------------- 1 file changed, 105 insertions(+), 86 deletions(-) (limited to 'test/test-pages/ietf-1') diff --git a/test/test-pages/ietf-1/expected.html b/test/test-pages/ietf-1/expected.html index aa5b470..0202963 100644 --- a/test/test-pages/ietf-1/expected.html +++ b/test/test-pages/ietf-1/expected.html @@ -1,6 +1,5 @@ -
- -[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 

INTERNET DRAFT                                      Michiel B. de Jong
+
 [Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]               
                                                                         
 Versions: 00 01 02 03 04                                                
                                                                         

+    
INTERNET DRAFT                                      Michiel B. de Jong
 Document: draft-dejong-remotestorage-04                   IndieHosters
                                                              F. Kooman
 Intended Status: Proposed Standard                       (independent)
@@ -53,7 +52,8 @@ Copyright Notice
 
 
 de Jong                                                         [Page 1]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -89,7 +89,7 @@ Table of Contents
   18. Authors' addresses............................................22
 
 
-1.  Introduction
+1.  Introduction
 
     Many services for data storage are available over the internet. This
     specification describes a vendor-independent interface for such
@@ -103,7 +103,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 2]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -122,7 +123,7 @@ Table of Contents
     The exact details of these four actions are described in this
     specification.
 
-2. Terminology
+2. Terminology
 
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ -135,7 +136,7 @@ Table of Contents
     implement the general requirement when such failure would result in
     interoperability failure.
 
-3. Storage model
+3. Storage model
 
     The server stores data in nodes that form a tree structure.
     Internal nodes are called 'folders' and leaf nodes are called
@@ -153,7 +154,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 3]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -163,7 +165,7 @@ Table of Contents
        * content length
        * content
 
-4. Requests
+4. Requests
 
     Client-to-server requests SHOULD be made over https [HTTPS], and
     servers MUST comply with HTTP/1.1 [HTTP]. Specifically, they
@@ -203,7 +205,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 4]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -253,7 +256,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 5]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -303,11 +307,12 @@ Table of Contents
 
 
 de Jong                                                         [Page 6]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
-5. Response codes
+5. Response codes
 
     Response codes SHOULD be given as defined by [HTTP, section 6] and
     [BEARER, section 3.1]. The following is a non-normative checklist
@@ -340,7 +345,7 @@ Table of Contents
     Clients SHOULD also handle the case where a response takes too long
     to arrive, or where no response is received at all.
 
-6. Versioning
+6. Versioning
 
     All successful requests MUST return an 'ETag' header [HTTP] with, in
     the case of GET, the current version, in the case of PUT, the new
@@ -353,7 +358,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 7]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -370,14 +376,14 @@ Table of Contents
     A provider MAY offer version rollback functionality to its users,
     but this specification does not define the user interface for that.
 
-7. CORS headers
+7. CORS headers
 
     All responses MUST carry CORS headers [CORS]. The server MUST also
     reply to OPTIONS requests as per CORS. For GET requests, a wildcard
     origin MAY be returned, but for PUT and DELETE requests, the
     response MUST echo back the Origin header sent by the client.
 
-8. Session description
+8. Session description
 
     The information that a client needs to receive in order to be able
     to connect to a server SHOULD reach the client as described in the
@@ -403,7 +409,8 @@ Table of Contents
 
 
 de Jong                                                         [Page 8]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -418,7 +425,7 @@ Table of Contents
     * https://storage.example.com/bob/public/documents/
     * https://storage.example.com/bob/public/documents/draft.txt
 
-9. Bearer tokens and access control
+9. Bearer tokens and access control
 
     A bearer token represents one or more access scopes. These access
     scopes are represented as strings of the form <module> <level>,
@@ -453,12 +460,13 @@ Table of Contents
 
 
 de Jong                                                         [Page 9]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
 
-10. Application-first bearer token issuance
+10. Application-first bearer token issuance
 
     To make a remoteStorage server available as 'the remoteStorage of
     <account> at <host>', exactly one link of the following format
@@ -503,7 +511,8 @@ Table of Contents
 
 
 de Jong                                                        [Page 10]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -533,7 +542,7 @@ Table of Contents
     client_id parameter in favor of relying on the redirect_uri
     parameter for client identification.
 
-11. Storage-first bearer token issuance
+11. Storage-first bearer token issuance
 
     The provider MAY also present a dashboard to the user, where they
     have some way to add open web app manifests [MANIFEST]. Adding a
@@ -553,7 +562,8 @@ Table of Contents
 
 
 de Jong                                                        [Page 11]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -591,19 +601,20 @@ Table of Contents
     debug tool, thus bypassing the need for an OAuth dance. Clients
     SHOULD NOT rely on this in production.
 
-12. Example wire transcripts
+12. Example wire transcripts
 
     The following examples are not normative ("\" indicates a line was
     wrapped).
 
-12.1. WebFinger
+12.1. WebFinger
 
     In application-first, an in-browser application might issue the
     following request, using XMLHttpRequest and CORS:
 
 
 de Jong                                                        [Page 12]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -643,7 +654,7 @@ motestorage-04",
            }]
          }
 
-12.2. OAuth dialog form
+12.2. OAuth dialog form
 
     Once the in-browser application has discovered the server's OAuth
     end-point, it will typically redirect the user to this URL, in
@@ -653,7 +664,8 @@ motestorage-04",
 
 
 de Jong                                                        [Page 13]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -673,16 +685,16 @@ unhosted.5apps.com&response_type=token HTTP/1.1
             <title>Allow access?</title>
         ...
 
-12.3. OAuth dialog form submission
+12.3. OAuth dialog form submission
 
     When the user submits the form, the request would look something
     like this:
 
         POST /oauth HTTP/1.1
         Host: 3pp.io:4439
-        Origin: https://3pp.io:4439
+        Origin: https://3pp.io:4439
         Content-Type: application/x-www-form-urlencoded
-        Referer: https://3pp.io:4439/oauth/michiel?redirect_uri=https%3\
+        Referer: https://3pp.io:4439/oauth/michiel?redirect_uri=https%3\
 A%2F%2Fdrinks-unhosted.5apps.com%2F&scope=myfavoritedrinks%3Arw&client_\
 id=https%3A%2F%2Fdrinks-unhosted.5apps.com&response_type=token
 
@@ -698,12 +710,13 @@ low
         Location:https://drinks-unhosted.5apps.com/#access_token=j2YnGt\
 XjzzzHNjkd1CJxoQubA1o%3D&token_type=bearer&state=
 
-12.4. OPTIONS preflight
+12.4. OPTIONS preflight
 
 
 
 de Jong                                                        [Page 14]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -714,46 +727,47 @@ XjzzzHNjkd1CJxoQubA1o%3D&token_type=bearer&state=
         OPTIONS /storage/michiel/myfavoritedrinks/ HTTP/1.1
         Host: 3pp.io:4439
         Access-Control-Request-Method: GET
-        Origin: https://drinks-unhosted.5apps.com
+        Origin: https://drinks-unhosted.5apps.com
         Access-Control-Request-Headers: Authorization
         Referer: https://drinks-unhosted.5apps.com/
 
     To which the server can for instance respond:
 
         HTTP/1.1 200 OK
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         Access-Control-Allow-Methods: GET, PUT, DELETE
         Access-Control-Allow-Headers: Authorization, Content-Length, Co\
 ntent-Type, Origin, X-Requested-With, If-Match, If-None-Match
 
-12.5. Initial PUT
+12.5. Initial PUT
 
     An initial PUT may contain an 'If-None-Match: *' header, like this:
 
         PUT /storage/michiel/myfavoritedrinks/test HTTP/1.1
         Host: 3pp.io:4439
         Content-Length: 91
-        Origin: https://drinks-unhosted.5apps.com
+        Origin: https://drinks-unhosted.5apps.com
         Authorization: Bearer j2YnGtXjzzzHNjkd1CJxoQubA1o=
         Content-Type: application/json; charset=UTF-8
         Referer: https://drinks-unhosted.5apps.com/?
         If-None-Match: *
 
-        {"name":"test","@context":"http://remotestorage.io/spec/modules\
+        {"name":"test","@context":"http://remotestorage.io/spec/modules\
 /myfavoritedrinks/drink"}
 
     And the server may respond with either a 201 Created or a 200 OK
     status:
 
         HTTP/1.1 201 Created
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         ETag: "1382694045000"
 
-12.6. Subsequent PUT
+12.6. Subsequent PUT
 
 
 de Jong                                                        [Page 15]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -764,7 +778,7 @@ ntent-Type, Origin, X-Requested-With, If-Match, If-None-Match
         PUT /storage/michiel/myfavoritedrinks/test HTTP/1.1
         Host: 3pp.io:4439
         Content-Length: 91
-        Origin: https://drinks-unhosted.5apps.com
+        Origin: https://drinks-unhosted.5apps.com
         Authorization: Bearer j2YnGtXjzzzHNjkd1CJxoQubA1o=
         Content-Type: application/json; charset=UTF-8
         Referer: https://drinks-unhosted.5apps.com/?
@@ -776,17 +790,17 @@ e.io/spec/modules/myfavoritedrinks/drink"}
     And the server may respond with a 412 Conflict or a 200 OK status:
 
         HTTP/1.1 200 OK
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         ETag: "1382694048000"
 
-12.7. GET
+12.7. GET
 
     A GET request would also include the bearer token, and optionally
     an If-None-Match header:
 
         GET /storage/michiel/myfavoritedrinks/test HTTP/1.1
         Host: 3pp.io:4439
-        Origin: https://drinks-unhosted.5apps.com
+        Origin: https://drinks-unhosted.5apps.com
         Authorization: Bearer j2YnGtXjzzzHNjkd1CJxoQubA1o=
         Referer: https://drinks-unhosted.5apps.com/?
         If-None-Match: "1382694045000", "1382694048000"
@@ -794,7 +808,7 @@ e.io/spec/modules/myfavoritedrinks/drink"}
     And the server may respond with a 304 Not Modified status:
 
         HTTP/1.1 304 Not Modified
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         ETag: "1382694048000"
 
     Or a 200 OK status, plus a response body:
@@ -803,11 +817,12 @@ e.io/spec/modules/myfavoritedrinks/drink"}
 
 
 de Jong                                                        [Page 16]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         Content-Type: application/json; charset=UTF-8
         Content-Length: 106
         ETag: "1382694048000"
@@ -821,7 +836,7 @@ ge.io/spec/modules/myfavoritedrinks/drink"}
     body:
 
         HTTP/1.1 200 OK
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         Content-Type: application/ld+json
         Content-Length: 171
         ETag: "1382694048000"
@@ -836,15 +851,15 @@ charset=UTF-8","Content-Length":106}}}
     Not Found status, and no ETag header:
 
         HTTP/1.1 404 Not Found
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
 
-12.8. DELETE
+12.8. DELETE
 
     A DELETE request may look like this:
 
         DELETE /storage/michiel/myfavoritedrinks/test HTTP/1.1
         Host: 3pp.io:4439
-        Origin: https://drinks-unhosted.5apps.com
+        Origin: https://drinks-unhosted.5apps.com
         Authorization: Bearer j2YnGtXjzzzHNjkd1CJxoQubA1o=
         Content-Type: application/json; charset=UTF-8
         Referer: https://drinks-unhosted.5apps.com/?
@@ -853,17 +868,18 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 17]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
     And the server may respond with a 412 Conflict or a 200 OK status:
 
         HTTP/1.1 412 Conflict
-        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
+        Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
         ETag: "1382694048000"
 
-13. Distributed versioning
+13. Distributed versioning
 
     This section is non-normative, and is intended to explain some of
     the design choices concerning ETags and folder listings. At the
@@ -903,7 +919,8 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 18]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -925,7 +942,7 @@ charset=UTF-8","Content-Length":106}}}
     but it is up to whichever client discovers a given version
     conflict, to resolve it.
 
-14. Security Considerations
+14. Security Considerations
 
     To prevent man-in-the-middle attacks, the use of https instead of
     http is important for both the interface itself and all end-points
@@ -953,7 +970,8 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 19]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -970,7 +988,7 @@ charset=UTF-8","Content-Length":106}}}
     The server SHOULD also detect and stop denial-of-service attacks
     that aim to overwhelm its interface with too much traffic.
 
-15. IANA Considerations
+15. IANA Considerations
 
     This document registers the 'remotestorage' link relation, as well
     as the following WebFinger properties:
@@ -980,7 +998,7 @@ charset=UTF-8","Content-Length":106}}}
       * "http://tools.ietf.org/html/rfc7233"
       * "http://remotestorage.io/spec/web-authoring"
 
-16. Acknowledgements
+16. Acknowledgements
 
     The authors would like to thank everybody who contributed to the
     development of this protocol, including Kenny Bentley, Javier Diaz,
@@ -993,86 +1011,88 @@ charset=UTF-8","Content-Length":106}}}
     Rick van Rein, Mark Nottingham, Julian Reschke, and Markus
     Lanthaler, among many others.
 
-17. References
+17. References
 
-17.1. Normative References
+17.1. Normative References
 
-    [WORDS]
+    [WORDS]
         Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.
 
 
 de Jong                                                        [Page 20]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
 
-    [IRI]
+    [IRI]
         Duerst, M., "Internationalized Resource Identifiers (IRIs)",
         RFC 3987, January 2005.
 
-    [WEBFINGER]
+    [WEBFINGER]
         Jones, P., Salguerio, G., Jones, M, and Smarr, J.,
         "WebFinger", RFC7033, September 2013.
 
-    [OAUTH]
+    [OAUTH]
         "Section 4.2: Implicit Grant", in: Hardt, D. (ed), "The OAuth
         2.0 Authorization Framework", RFC6749, October 2012.
 
-17.2. Informative References
+17.2. Informative References
 
-    [HTTPS]
+    [HTTPS]
         Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
 
-    [HTTP]
+    [HTTP]
         Fielding et al., "Hypertext Transfer Protocol (HTTP/1.1):
         Semantics and Content", RFC7231, June 2014.
 
-    [COND]
+    [COND]
         Fielding et al., "Hypertext Transfer Protocol (HTTP/1.1):
         Conditional Requests", RFC7232, June 2014.
 
-    [RANGE]
+    [RANGE]
         Fielding et al., "Hypertext Transfer Protocol (HTTP/1.1):
         Conditional Requests", RFC7233, June 2014.
 
-    [SPDY]
+    [SPDY]
         Mark Belshe, Roberto Peon, "SPDY Protocol - Draft 3.1", http://
         www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1,
         September 2013.
 
-    [JSON-LD]
+    [JSON-LD]
         M. Sporny, G. Kellogg, M. Lanthaler, "JSON-LD 1.0", W3C
         Proposed Recommendation,
         http://www.w3.org/TR/2014/REC-json-ld-20140116/, January 2014.
 
-    [CORS]
+    [CORS]
         van Kesteren, Anne (ed), "Cross-Origin Resource Sharing --
         W3C Candidate Recommendation 29 January 2013",
 
 
 de Jong                                                        [Page 21]
-
 
+

+    
 
 Internet-Draft              remoteStorage                  December 2014
 
 
         http://www.w3.org/TR/cors/, January 2013.
 
-    [MANIFEST]
+    [MANIFEST]
         Mozilla Developer Network (ed), "App manifest -- Revision
         330541", https://developer.mozilla.org/en-
         US/Apps/Build/Manifest$revision/566677, April 2014.
 
-    [DATASTORE]
+    [DATASTORE]
         "WebAPI/DataStore", MozillaWiki, retrieved May 2014.
         https://wiki.mozilla.org/WebAPI/DataStore#Manifest
 
-    [KERBEROS]
+    [KERBEROS]
         C. Neuman et al., "The Kerberos Network Authentication Service
         (V5)", RFC4120, July 2005.
 
-    [BEARER]
+    [BEARER]
         M. Jones, D. Hardt, "The OAuth 2.0 Authorization Framework:
         Bearer Token Usage", RFC6750, October 2012.
 
@@ -1081,7 +1101,7 @@ charset=UTF-8","Content-Length":106}}}
         September 2014. https://github.com/michielbdejong/resite/wiki
         /Using-remoteStorage-for-web-authoring
 
-18. Authors' addresses
+18. Authors' addresses
 
     Michiel B. de Jong
     IndieHosters
@@ -1104,7 +1124,6 @@ charset=UTF-8","Content-Length":106}}}
 
 de Jong                                                        [Page 22]
 
-
Html markup produced by rfcmarkup 1.111, available from
+

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/ - -

\ No newline at end of file + -- cgit v1.2.3