From 984ded395de1982a773f9639481552550c5e17ef Mon Sep 17 00:00:00 2001 From: Andres Rey Date: Sat, 17 Dec 2016 10:34:05 -0300 Subject: Corrected more test cases --- test/test-pages/ietf-1/expected.html | 174 +++++++++++++++++------------------ 1 file changed, 86 insertions(+), 88 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 5ce872f..8d80a2e 100644 --- a/test/test-pages/ietf-1/expected.html +++ b/test/test-pages/ietf-1/expected.html @@ -1,9 +1,7 @@ -[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
+

+   
+[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)
 Expires: 18 June 2015                                 15 December 2014
@@ -24,7 +22,7 @@ Abstract
 Status of this Memo
 
    This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
+   provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
@@ -43,7 +41,7 @@ Copyright Notice
    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors. All rights reserved.
 
-   This document is subject to BCP 78 and the IETF Trust's Legal
+   This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -55,7 +53,7 @@ Copyright Notice
 
 
 de Jong                                                         [Page 1]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -91,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
@@ -105,7 +103,7 @@ Table of Contents
 
 
 de Jong                                                         [Page 2]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -124,11 +122,11 @@ 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
-    document are to be interpreted as described in RFC 2119 [WORDS].
+    document are to be interpreted as described in RFC 2119 [WORDS].
 
     "SHOULD" and "SHOULD NOT" are appropriate when valid exceptions to a
     general requirement are known to exist or appear to exist, and it is
@@ -137,7 +135,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
@@ -155,7 +153,7 @@ Table of Contents
 
 
 de Jong                                                         [Page 3]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -165,7 +163,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
@@ -205,7 +203,7 @@ Table of Contents
 
 
 de Jong                                                         [Page 4]
-

+

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

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -305,11 +303,11 @@ 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
@@ -342,7 +340,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
@@ -355,7 +353,7 @@ Table of Contents
 
 
 de Jong                                                         [Page 7]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -372,14 +370,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
@@ -397,7 +395,7 @@ Table of Contents
          can however be reused in subsequent interactions with the same
          client, as long as that client is still trusted. Example:
          * 'ofb24f1ac3973e70j6vts19qr9v2eei'
-       * <storage_api>, always 'draft-dejong-remotestorage-04' for this
+       * <storage_api>, always 'draft-dejong-remotestorage-04' for this
          alternative version of the specification.
 
     The client can make its requests using https with CORS and bearer
@@ -405,7 +403,7 @@ Table of Contents
 
 
 de Jong                                                         [Page 8]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -420,7 +418,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>,
@@ -455,12 +453,12 @@ 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
@@ -505,7 +503,7 @@ Table of Contents
 
 
 de Jong                                                        [Page 10]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -535,7 +533,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
@@ -555,7 +553,7 @@ Table of Contents
 
 
 de Jong                                                        [Page 11]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -593,19 +591,19 @@ 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
 
 
@@ -634,7 +632,7 @@ g.com HTTP/1.1
              "href": "https://3pp.io:4439/storage/michiel",
              "rel": "remotestorage",
              "properties": {
-               "http://remotestorage.io/spec/version": "draft-dejong-re\
+               "http://remotestorage.io/spec/version": "draft-dejong-re\
 motestorage-04",
                "http://tools.ietf.org/html/rfc6749#section-4.2": "https\
 ://3pp.io:4439/oauth/michiel",
@@ -645,7 +643,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
@@ -655,7 +653,7 @@ motestorage-04",
 
 
 de Jong                                                        [Page 13]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -675,7 +673,7 @@ 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:
@@ -700,12 +698,12 @@ 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
 
 
@@ -728,7 +726,7 @@ XjzzzHNjkd1CJxoQubA1o%3D&token_type=bearer&state=
         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:
 
@@ -751,11 +749,11 @@ ntent-Type, Origin, X-Requested-With, If-Match, If-None-Match
         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
 
 
@@ -781,7 +779,7 @@ e.io/spec/modules/myfavoritedrinks/drink"}
         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:
@@ -805,7 +803,7 @@ e.io/spec/modules/myfavoritedrinks/drink"}
 
 
 de Jong                                                        [Page 16]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -840,7 +838,7 @@ charset=UTF-8","Content-Length":106}}}
         HTTP/1.1 404 Not Found
         Access-Control-Allow-Origin: https://drinks-unhosted.5apps.com
 
-12.8. DELETE
+12.8. DELETE
 
     A DELETE request may look like this:
 
@@ -855,7 +853,7 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 17]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -865,7 +863,7 @@ charset=UTF-8","Content-Length":106}}}
         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
@@ -905,7 +903,7 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 18]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -927,7 +925,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
@@ -955,7 +953,7 @@ charset=UTF-8","Content-Length":106}}}
 
 
 de Jong                                                        [Page 19]
-

+

 Internet-Draft              remoteStorage                  December 2014
 
 
@@ -972,7 +970,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:
@@ -982,7 +980,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,
@@ -995,95 +993,95 @@ 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.
+        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.
+        RFC 3987, January 2005.
 
-    [WEBFINGER]
+    [WEBFINGER]
         Jones, P., Salguerio, G., Jones, M, and Smarr, J.,
-        "WebFinger", RFC7033, September 2013.
+        "WebFinger", RFC7033, September 2013.
 
-    [OAUTH]
+    [OAUTH]
         "Section 4.2: Implicit Grant", in: Hardt, D. (ed), "The OAuth
-        2.0 Authorization Framework", RFC6749, October 2012.
+        2.0 Authorization Framework", RFC6749, October 2012.
 
-17.2. Informative References
+17.2. Informative References
 
-    [HTTPS]
-        Rescorla, E., "HTTP Over TLS", RFC2818, May 2000.
+    [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.
+        Semantics and Content", RFC7231, June 2014.
 
-    [COND]
+    [COND]
         Fielding et al., "Hypertext Transfer Protocol (HTTP/1.1):
-        Conditional Requests", RFC7232, June 2014.
+        Conditional Requests", RFC7232, June 2014.
 
-    [RANGE]
+    [RANGE]
         Fielding et al., "Hypertext Transfer Protocol (HTTP/1.1):
-        Conditional Requests", RFC7233, June 2014.
+        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.
+        (V5)", RFC4120, July 2005.
 
-    [BEARER]
+    [BEARER]
         M. Jones, D. Hardt, "The OAuth 2.0 Authorization Framework:
-        Bearer Token Usage", RFC6750, October 2012.
+        Bearer Token Usage", RFC6750, October 2012.
 
     []
         "Using remoteStorage for web authoring", reSite wiki, retrieved
         September 2014. https://github.com/michielbdejong/resite/wiki
         /Using-remoteStorage-for-web-authoring
 
-18. Authors' addresses
+18. Authors' addresses
 
     Michiel B. de Jong
     IndieHosters
@@ -1106,7 +1104,7 @@ 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 + + \ No newline at end of file -- cgit v1.2.3