summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/text/qbytearray
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2022-10-27 15:44:08 -0700
committerThiago Macieira <thiago.macieira@intel.com>2022-11-05 11:15:40 -0700
commitf642bdf69e2cc53680f139b56b0b64b0fd74fd5d (patch)
tree49cce341ad7cf6673681bcbfcad8fabe2750bf72 /tests/auto/corelib/text/qbytearray
parent8222e06d12a4e2a84ce1161abd0ceb58622c740b (diff)
QByteArray: move the high-memory-using and slot tests away
Otherwise, tst_QByteArray takes 97 seconds on my laptop to run. Makes design iteration difficult. Pick-to: 6.4 Change-Id: I07ec23f3cb174fb197c3fffd17220e6737907415 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Diffstat (limited to 'tests/auto/corelib/text/qbytearray')
-rw-r--r--tests/auto/corelib/text/qbytearray/.gitattributes1
-rw-r--r--tests/auto/corelib/text/qbytearray/CMakeLists.txt4
-rw-r--r--tests/auto/corelib/text/qbytearray/rfc3252.txt899
-rw-r--r--tests/auto/corelib/text/qbytearray/tst_qbytearray.cpp199
4 files changed, 0 insertions, 1103 deletions
diff --git a/tests/auto/corelib/text/qbytearray/.gitattributes b/tests/auto/corelib/text/qbytearray/.gitattributes
deleted file mode 100644
index e04709aa2e..0000000000
--- a/tests/auto/corelib/text/qbytearray/.gitattributes
+++ /dev/null
@@ -1 +0,0 @@
-rfc3252.txt -crlf
diff --git a/tests/auto/corelib/text/qbytearray/CMakeLists.txt b/tests/auto/corelib/text/qbytearray/CMakeLists.txt
index b1679c72f3..1f2aeae6d0 100644
--- a/tests/auto/corelib/text/qbytearray/CMakeLists.txt
+++ b/tests/auto/corelib/text/qbytearray/CMakeLists.txt
@@ -7,15 +7,11 @@
## tst_qbytearray Test:
#####################################################################
-# Collect test data
-list(APPEND test_data "rfc3252.txt")
-
qt_internal_add_test(tst_qbytearray
SOURCES
tst_qbytearray.cpp
LIBRARIES
Qt::CorePrivate
- TESTDATA ${test_data}
)
## Scopes:
diff --git a/tests/auto/corelib/text/qbytearray/rfc3252.txt b/tests/auto/corelib/text/qbytearray/rfc3252.txt
deleted file mode 100644
index b80c61bf0a..0000000000
--- a/tests/auto/corelib/text/qbytearray/rfc3252.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group H. Kennedy
-Request for Comments: 3252 Mimezine
-Category: Informational 1 April 2002
-
-
- Binary Lexical Octet Ad-hoc Transport
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document defines a reformulation of IP and two transport layer
- protocols (TCP and UDP) as XML applications.
-
-1. Introduction
-
-1.1. Overview
-
- This document describes the Binary Lexical Octet Ad-hoc Transport
- (BLOAT): a reformulation of a widely-deployed network-layer protocol
- (IP [RFC791]), and two associated transport layer protocols (TCP
- [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
- describes methods for transporting BLOAT over Ethernet and IEEE 802
- networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
- across the public Internet.
-
-1.2. Motivation
-
- The wild popularity of XML as a basis for application-level protocols
- such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
- Object Access Protocol [SOAP], and Jabber [JABBER] prompted
- investigation into the possibility of extending the use of XML in the
- protocol stack. Using XML at both the transport and network layer in
- addition to the application layer would provide for an amazing amount
- of power and flexibility while removing dependencies on proprietary
- and hard-to-understand binary protocols. This protocol unification
- would also allow applications to use a single XML parser for all
- aspects of their operation, eliminating developer time spent figuring
- out the intricacies of each new protocol, and moving the hard work of
-
-
-
-
-Kennedy Informational [Page 1]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- parsing to the XML toolset. The use of XML also mitigates concerns
- over "network vs. host" byte ordering which is at the root of many
- network application bugs.
-
-1.3. Relation to Existing Protocols
-
- The reformulations specified in this RFC follow as closely as
- possible the spirit of the RFCs on which they are based, and so MAY
- contain elements or attributes that would not be needed in a pure
- reworking (e.g. length attributes, which are implicit in XML.)
-
- The layering of network and transport protocols are maintained in
- this RFC despite the optimizations that could be made if the line
- were somewhat blurred (i.e. merging TCP and IP into a single, larger
- element in the DTD) in order to foster future use of this protocol as
- a basis for reformulating other protocols (such as ICMP.)
-
- Other than the encoding, the behavioral aspects of each of the
- existing protocols remain unchanged. Routing, address spaces, TCP
- congestion control, etc. behave as specified in the extant standards.
- Adapting to new standards and experimental algorithm heuristics for
- improving performance will become much easier once the move to BLOAT
- has been completed.
-
-1.4. Requirement Levels
-
- 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 BCP 14, RFC 2119
- [RFC2119].
-
-2. IPoXML
-
- This protocol MUST be implemented to be compliant with this RFC.
- IPoXML is the root protocol REQUIRED for effective use of TCPoXML
- (section 3.) and higher-level application protocols.
-
- The DTD for this document type can be found in section 7.1.
-
- The routing of IPoXML can be easily implemented on hosts with an XML
- parser, as the regular structure lends itself handily to parsing and
- validation of the document/datagram and then processing the
- destination address, TTL, and checksum before sending it on to its
- next-hop.
-
- The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
- wider deployment of IPv4 and the fact that implementing IPv6 as XML
- would have exceeded the 1500 byte Ethernet MTU.
-
-
-
-Kennedy Informational [Page 2]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- All BLOAT implementations MUST use - and specify - the UTF-8 encoding
- of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
- formed and include the XMLDecl.
-
-2.1. IP Description
-
- A number of items have changed (for the better) from the original IP
- specification. Bit-masks, where present have been converted into
- human-readable values. IP addresses are listed in their dotted-
- decimal notation [RFC1123]. Length and checksum values are present
- as decimal integers.
-
- To calculate the length and checksum fields of the IP element, a
- canonicalized form of the element MUST be used. The canonical form
- SHALL have no whitespace (including newline characters) between
- elements and only one space character between attributes. There
- SHALL NOT be a space following the last attribute in an element.
-
- An iterative method SHOULD be used to calculate checksums, as the
- length field will vary based on the size of the checksum.
-
- The payload element bears special attention. Due to the character
- set restrictions of XML, the payload of IP datagrams (which MAY
- contain arbitrary data) MUST be encoded for transport. This RFC
- REQUIRES the contents of the payload to be encoded in the base-64
- encoding of RFC 2045 [RFC2045], but removes the requirement that the
- encoded output MUST be wrapped on 76-character lines.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kennedy Informational [Page 3]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
-2.2. Example Datagram
-
- The following is an example IPoXML datagram with an empty payload:
-
- <?xml version="1.0" encoding="UTF-8"?>
- <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
- <ip>
- <header length="474">
- <version value="4"/>
- <tos precedence="Routine" delay="Normal" throughput="Normal"
- relibility="Normal" reserved="0"/>
- <total.length value="461"/>
- <id value="1"/>
- <flags reserved="0" df="dont" mf="last"/>
- <offset value="0"/>
- <ttl value="255"/>
- <protocol value="6"/>
- <checksum value="8707"/>
- <source address="10.0.0.22"/>
- <destination address="10.0.0.1"/>
- <options>
- <end copied="0" class="0" number="0"/>
- </options>
- <padding pad="0"/>
- </header>
- <payload>
- </payload>
- </ip>
-
-3. TCPoXML
-
- This protocol MUST be implemented to be compliant with this RFC. The
- DTD for this document type can be found in section 7.2.
-
-3.1. TCP Description
-
- A number of items have changed from the original TCP specification.
- Bit-masks, where present have been converted into human-readable
- values. Length and checksum and port values are present as decimal
- integers.
-
- To calculate the length and checksum fields of the TCP element, a
- canonicalized form of the element MUST be used as in section 2.1.
-
- An iterative method SHOULD be used to calculate checksums as in
- section 2.1.
-
- The payload element MUST be encoded as in section 2.1.
-
-
-
-Kennedy Informational [Page 4]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- The TCP offset element was expanded to a maximum of 255 from 16 to
- allow for the increased size of the header in XML.
-
- TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
- as well as the <!DOCTYPE> declaration.
-
-3.2. Example Datagram
-
- The following is an example TCPoXML datagram with an empty payload:
-
- <?xml version="1.0" encoding="UTF-8"?>
- <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
- <tcp>
- <tcp.header>
- <src port="31415"/>
- <dest port="42424"/>
- <sequence number="322622954"/>
- <acknowledgement number="689715995"/>
- <offset number=""/>
- <reserved value="0"/>
- <control syn="1" ack="1"/>
- <window size="1"/>
- <urgent pointer="0"/>
- <checksum value="2988"/>
- <tcp.options>
- <tcp.end kind="0"/>
- </tcp.options>
- <padding pad="0"/>
- </tcp.header>
- <payload>
- </payload>
- </tcp>
-
-4. UDPoXML
-
- This protocol MUST be implemented to be compliant with this RFC. The
- DTD for this document type can be found in section 7.3.
-
-4.1. UDP Description
-
- A number of items have changed from the original UDP specification.
- Bit-masks, where present have been converted into human-readable
- values. Length and checksum and port values are present as decimal
- integers.
-
-
-
-
-
-
-
-Kennedy Informational [Page 5]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- To calculate the length and checksum fields of the UDP element, a
- canonicalized form of the element MUST be used as in section 2.1. An
- iterative method SHOULD be used to calculate checksums as in section
- 2.1.
-
- The payload element MUST be encoded as in section 2.1.
-
- UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
- as well as the <!DOCTYPE> declaration.
-
-4.2. Example Datagram
-
- The following is an example UDPoXML datagram with an empty payload:
-
- <?xml version="1.0" encoding="UTF-8"?>
- <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
- <udp>
- <udp.header>
- <src port="31415"/>
- <dest port="42424"/>
- <udp.length value="143"/>
- <checksum value="2988"/>
- </udp.header>
- <payload>
- </payload>
- </udp>
-
-5. Network Transport
-
- This document provides for the transmission of BLOAT datagrams over
- two common families of physical layer transport. Future RFCs will
- address additional transports as routing vendors catch up to the
- specification, and we begin to see BLOAT routed across the Internet
- backbone.
-
-5.1. Ethernet
-
- BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
- exception that the type field of the Ethernet frame MUST contain the
- value 0xBEEF. The first 5 octets of the Ethernet frame payload will
- be 0x3c 3f 78 6d 6c ("<?xml".)
-
-5.2. IEEE 802
-
- BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
- that the protocol type code for IPoXML is 0xBEEF.
-
-
-
-
-
-Kennedy Informational [Page 6]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
-6. Gatewaying over IP
-
- In order to facilitate the gradual introduction of BLOAT into the
- public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
- gateway between networks that run BLOAT natively on their LANs.
-
-7. DTDs
-
- The Transport DTDs (7.2. and 7.3.) build on the definitions in the
- Network DTD (7.1.)
-
- The DTDs are referenced by their PubidLiteral and SystemLiteral (from
- [XML]) although it is understood that most IPoXML implementations
- will not need to pull down the DTD, as it will normally be embedded
- in the implementation, and presents something of a catch-22 if you
- need to load part of your network protocol over the network.
-
-7.1. IPoXML DTD
-
- <!--
- DTD for IP over XML.
- Refer to this DTD as:
-
- <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
- -->
- <!--
- DTD data types:
-
- Digits [0..9]+
-
- Precedence "NetworkControl | InternetworkControl |
- CRITIC | FlashOverride | Flash | Immediate |
- Priority | Routine"
-
- IP4Addr "dotted-decimal" notation of [RFC1123]
-
- Class [0..3]
-
- Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
- Restricted | Secret | Top Secret | Reserved"
-
- Compartments [0..65535]
-
- Handling [0..65535]
-
- TCC [0..16777216]
-
- -->
-
-
-
-Kennedy Informational [Page 7]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- <!ENTITY % Digits "CDATA">
- <!ENTITY % Precedence "CDATA">
- <!ENTITY % IP4Addr "CDATA">
- <!ENTITY % Class "CDATA">
- <!ENTITY % Sec "CDATA">
- <!ENTITY % Compartments "CDATA">
- <!ENTITY % Handling "CDATA">
- <!ENTITY % TCC "CDATA">
-
- <!ELEMENT ip (header, payload)>
-
- <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
- protocol, checksum, source, destination, options,
- padding)>
- <!-- length of header in 32-bit words -->
- <!ATTLIST header
- length %Digits; #REQUIRED>
-
- <!ELEMENT version EMPTY>
- <!-- ip version. SHOULD be "4" -->
- <!ATTLIST version
- value %Digits; #REQUIRED>
-
- <!ELEMENT tos EMPTY>
- <!ATTLIST tos
- precedence %Precedence; #REQUIRED
- delay (normal | low) #REQUIRED
- throughput (normal | high) #REQUIRED
- relibility (normal | high) #REQUIRED
- reserved CDATA #FIXED "0">
-
- <!ELEMENT total.length EMPTY>
- <!--
- total length of datagram (header and payload) in octets, MUST be
- less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
- ethernets).
- -->
- <!ATTLIST total.length
- value %Digits; #REQUIRED>
-
- <!ELEMENT id EMPTY>
- <!-- 0 <= id <= 65,535 -->
- <!ATTLIST id
- value %Digits; #REQUIRED>
-
- <!ELEMENT flags EMPTY>
- <!-- df = don't fragment, mf = more fragments -->
- <!ATTLIST flags
-
-
-
-Kennedy Informational [Page 8]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- reserved CDATA #FIXED "0"
- df (may|dont) #REQUIRED
- mf (last|more) #REQUIRED>
-
- <!ELEMENT offset EMPTY>
- <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
- <!ATTLIST offset
- value %Digits; #REQUIRED>
-
- <!ELEMENT ttl EMPTY>
- <!-- 0 <= ttl <= 255 -->
- <!ATTLIST ttl
- value %Digits; #REQUIRED>
-
- <!ELEMENT protocol EMPTY>
- <!-- 0 <= protocol <= 255 (per IANA) -->
- <!ATTLIST protocol
- value %Digits; #REQUIRED>
-
- <!ELEMENT checksum EMPTY>
- <!-- 0 <= checksum <= 65535 (over header only) -->
- <!ATTLIST checksum
- value %Digits; #REQUIRED>
-
- <!ELEMENT source EMPTY>
- <!ATTLIST source
- address %IP4Addr; #REQUIRED>
-
- <!ELEMENT destination EMPTY>
- <!ATTLIST destination
- address %IP4Addr; #REQUIRED>
-
- <!ELEMENT options ( end | noop | security | loose | strict | record
- | stream | timestamp )*>
-
- <!ELEMENT end EMPTY>
- <!ATTLIST end
- copied (0|1) #REQUIRED
- class CDATA #FIXED "0"
- number CDATA #FIXED "0">
-
- <!ELEMENT noop EMPTY>
- <!ATTLIST noop
- copied (0|1) #REQUIRED
- class CDATA #FIXED "0"
- number CDATA #FIXED "1">
-
- <!ELEMENT security EMPTY>
-
-
-
-Kennedy Informational [Page 9]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- <!ATTLIST security
- copied CDATA #FIXED "1"
- class CDATA #FIXED "0"
- number CDATA #FIXED "2"
- length CDATA #FIXED "11"
- security %Sec; #REQUIRED
- compartments %Compartments; #REQUIRED
- handling %Handling; #REQUIRED
- tcc %TCC; #REQUIRED>
- <!ELEMENT loose (hop)+>
- <!ATTLIST loose
- copied CDATA #FIXED "1"
- class CDATA #FIXED "0"
- number CDATA #FIXED "3"
- length %Digits; #REQUIRED
- pointer %Digits; #REQUIRED>
-
- <!ELEMENT hop EMPTY>
- <!ATTLIST hop
- address %IP4Addr; #REQUIRED>
-
- <!ELEMENT strict (hop)+>
- <!ATTLIST strict
- copied CDATA #FIXED "1"
- class CDATA #FIXED "0"
- number CDATA #FIXED "9"
- length %Digits; #REQUIRED
- pointer %Digits; #REQUIRED>
-
- <!ELEMENT record (hop)+>
- <!ATTLIST record
- copied CDATA #FIXED "0"
- class CDATA #FIXED "0"
- number CDATA #FIXED "7"
- length %Digits; #REQUIRED
- pointer %Digits; #REQUIRED>
-
- <!ELEMENT stream EMPTY>
- <!-- 0 <= id <= 65,535 -->
- <!ATTLIST stream
- copied CDATA #FIXED "1"
- class CDATA #FIXED "0"
- number CDATA #FIXED "8"
- length CDATA #FIXED "4"
- id %Digits; #REQUIRED>
-
- <!ELEMENT timestamp (tstamp)+>
- <!-- 0 <= oflw <=15 -->
-
-
-
-Kennedy Informational [Page 10]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- <!ATTLIST timestamp
- copied CDATA #FIXED "0"
- class CDATA #FIXED "2"
- number CDATA #FIXED "4"
- length %Digits; #REQUIRED
- pointer %Digits; #REQUIRED
- oflw %Digits; #REQUIRED
- flag (0 | 1 | 3) #REQUIRED>
-
- <!ELEMENT tstamp EMPTY>
- <!ATTLIST tstamp
- time %Digits; #REQUIRED
- address %IP4Addr; #IMPLIED>
- <!--
- padding to bring header to 32-bit boundary.
- pad MUST be "0"*
- -->
- <!ELEMENT padding EMPTY>
- <!ATTLIST padding
- pad CDATA #REQUIRED>
-
- <!-- payload MUST be encoded as base-64 [RFC2045], as modified
- by section 2.1 of this RFC -->
- <!ELEMENT payload (CDATA)>
-
-7.2. TCPoXML DTD
-
- <!--
- DTD for TCP over XML.
- Refer to this DTD as:
-
- <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
- -->
-
- <!-- the pseudoheader is only included for checksum calculations -->
- <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
-
- <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
- reserved, control, window, checksum, urgent,
- tcp.options, padding)>
-
- <!ELEMENT src EMPTY>
- <!-- 0 <= port <= 65,535 -->
- <!ATTLIST src
- port %Digits; #REQUIRED>
-
- <!ELEMENT dest EMPTY>
- <!-- 0 <= port <= 65,535 -->
-
-
-
-Kennedy Informational [Page 11]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- <!ATTLIST dest
- port %Digits; #REQUIRED>
-
- <!ELEMENT sequence EMPTY>
- <!-- 0 <= number <= 4294967295 -->
- <!ATTLIST sequence
- number %Digits; #REQUIRED>
-
- <!ELEMENT acknowledgement EMPTY>
- <!-- 0 <= number <= 4294967295 -->
- <!ATTLIST acknowledgement
- number %Digits; #REQUIRED>
-
- <!ELEMENT offset EMPTY>
- <!-- 0 <= number <= 255 -->
- <!ATTLIST offset
- number %Digits; #REQUIRED>
-
- <!ELEMENT reserved EMPTY>
- <!ATTLIST reserved
- value CDATA #FIXED "0">
-
- <!ELEMENT control EMPTY>
- <!ATTLIST control
- urg (0|1) #IMPLIED
- ack (0|1) #IMPLIED
- psh (0|1) #IMPLIED
- rst (0|1) #IMPLIED
- syn (0|1) #IMPLIED
- fin (0|1) #IMPLIED>
-
- <!ELEMENT window EMPTY>
- <!-- 0 <= size <= 65,535 -->
- <!ATTLIST window
- size %Digits; #REQUIRED>
-
- <!--
- checksum as in ip, but with
- the following pseudo-header added into the tcp element:
- -->
- <!ELEMENT tcp.pseudoheader (source, destination, protocol,
- tcp.length)>
-
- <!--
- tcp header + data length in octets. does not include the size of
-
- the pseudoheader.
- -->
-
-
-
-Kennedy Informational [Page 12]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- <!ELEMENT tcp.length EMPTY>
- <!ATTLIST tcp.length
- value %Digits; #REQUIRED>
-
- <!ELEMENT urgent EMPTY>
- <!-- 0 <= pointer <= 65,535 -->
- <!ATTLIST urgent
- pointer %Digits; #REQUIRED>
-
- <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
-
- <!ELEMENT tcp.end EMPTY>
- <!ATTLIST tcp.end
- kind CDATA #FIXED "0">
-
- <!ELEMENT tcp.noop EMPTY>
- <!ATTLIST tcp.noop
- kind CDATA #FIXED "1">
-
- <!ELEMENT tcp.mss EMPTY>
- <!ATTLIST tcp.mss
- kind CDATA #FIXED "2"
- length CDATA #FIXED "4"
- size %Digits; #REQUIRED>
-
-7.3. UDPoXML DTD
-
- <!--
- DTD for UDP over XML.
- Refer to this DTD as:
-
- <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
- -->
-
- <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
-
- <!ELEMENT udp.header (src, dest, udp.length, checksum)>
-
- <!ELEMENT udp.pseudoheader (source, destination, protocol,
- udp.length)>
-
- <!--
- udp header + data length in octets. does not include the size of
- the pseudoheader.
- -->
- <!ELEMENT udp.length EMPTY>
- <!ATTLIST udp.length
- value %Digits; #REQUIRED>
-
-
-
-Kennedy Informational [Page 13]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
-8. Security Considerations
-
- XML, as a subset of SGML, has the same security considerations as
- specified in SGML Media Types [RFC1874]. Security considerations
- that apply to IP, TCP and UDP also likely apply to BLOAT as it does
- not attempt to correct for issues not related to message format.
-
-9. References
-
- [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
- February 2002. (Work in Progress)
-
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- August 1980.
-
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
- [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
- 793, September 1981.
-
- [RFC894] Hornig, C., "Standard for the Transmission of IP
- Datagrams over Ethernet Networks.", RFC 894, April 1984.
-
- [RFC1042] Postel, J. and J. Reynolds, "Standard for the
- Transmission of IP Datagrams Over IEEE 802 Networks", STD
- 43, RFC 1042, February 1988.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -
- Application and Support", RFC 1123, October 1989.
-
- [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
- 1995.
-
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
- October 1996.
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-
-
-
-
-Kennedy Informational [Page 14]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
- [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
- RFC 3080, March 2001.
-
- [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
- Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
- "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
- Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
-
- [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
- Markup Language (XML)" World Wide Web Consortium
- Recommendation REC- xml-19980210.
- http://www.w3.org/TR/1998/REC-xml-19980210
-
-10. Author's Address
-
- Hugh Kennedy
- Mimezine
- 1060 West Addison
- Chicago, IL 60613
- USA
-
- EMail: kennedyh@engin.umich.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kennedy Informational [Page 15]
-
-RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kennedy Informational [Page 16]
-
diff --git a/tests/auto/corelib/text/qbytearray/tst_qbytearray.cpp b/tests/auto/corelib/text/qbytearray/tst_qbytearray.cpp
index 7e14894114..9794247965 100644
--- a/tests/auto/corelib/text/qbytearray/tst_qbytearray.cpp
+++ b/tests/auto/corelib/text/qbytearray/tst_qbytearray.cpp
@@ -12,11 +12,6 @@
#include "../shared/test_number_shared.h"
-#include <q20iterator.h>
-
-#include <stdexcept>
-#include <string_view>
-
class tst_QByteArray : public QObject
{
Q_OBJECT
@@ -28,14 +23,6 @@ private slots:
void swap();
void qChecksum_data();
void qChecksum();
-#ifndef QT_NO_COMPRESS
- void qCompress_data();
- void qCompress();
- void qUncompressCorruptedData_data();
- void qUncompressCorruptedData();
- void qUncompress4GiBPlus();
- void qCompressionZeroTermination();
-#endif
void constByteArray();
void leftJustified();
void rightJustified();
@@ -46,7 +33,6 @@ private slots:
void split();
void base64_data();
void base64();
- void base64_2GiB();
void fromBase64_data();
void fromBase64();
void qvsnprintf();
@@ -240,152 +226,6 @@ void tst_QByteArray::qChecksum()
QCOMPARE(::qChecksum(QByteArrayView(data.constData(), len), standard), static_cast<quint16>(checksum));
}
-#ifndef QT_NO_COMPRESS
-void tst_QByteArray::qCompress_data()
-{
- QTest::addColumn<QByteArray>("ba");
-
- const int size1 = 1024*1024;
- QByteArray ba1( size1, 0 );
-
- QTest::newRow( "00" ) << QByteArray();
-
- int i;
- for ( i=0; i<size1; i++ )
- ba1[i] = (char)( i / 1024 );
- QTest::newRow( "01" ) << ba1;
-
- for ( i=0; i<size1; i++ )
- ba1[i] = (char)( i % 256 );
- QTest::newRow( "02" ) << ba1;
-
- ba1.fill( 'A' );
- QTest::newRow( "03" ) << ba1;
-
- QFile file( QFINDTESTDATA("rfc3252.txt") );
- QVERIFY( file.open(QIODevice::ReadOnly) );
- QTest::newRow( "04" ) << file.readAll();
-}
-
-void tst_QByteArray::qCompress()
-{
- QFETCH( QByteArray, ba );
- QByteArray compressed = ::qCompress( ba );
- QTEST( ::qUncompress( compressed ), "ba" );
-}
-
-void tst_QByteArray::qUncompressCorruptedData_data()
-{
- QTest::addColumn<QByteArray>("in");
-
- QTest::newRow("0x00000000") << QByteArray("\x00\x00\x00\x00", 4);
- QTest::newRow("0x000000ff") << QByteArray("\x00\x00\x00\xff", 4);
- QTest::newRow("0x3f000000") << QByteArray("\x3f\x00\x00\x00", 4);
- QTest::newRow("0x3fffffff") << QByteArray("\x3f\xff\xff\xff", 4);
- QTest::newRow("0x7fffff00") << QByteArray("\x7f\xff\xff\x00", 4);
- QTest::newRow("0x7fffffff") << QByteArray("\x7f\xff\xff\xff", 4);
- QTest::newRow("0x80000000") << QByteArray("\x80\x00\x00\x00", 4);
- QTest::newRow("0x800000ff") << QByteArray("\x80\x00\x00\xff", 4);
- QTest::newRow("0xcf000000") << QByteArray("\xcf\x00\x00\x00", 4);
- QTest::newRow("0xcfffffff") << QByteArray("\xcf\xff\xff\xff", 4);
- QTest::newRow("0xffffff00") << QByteArray("\xff\xff\xff\x00", 4);
- QTest::newRow("0xffffffff") << QByteArray("\xff\xff\xff\xff", 4);
-}
-
-// This test is expected to produce some warning messages in the test output.
-void tst_QByteArray::qUncompressCorruptedData()
-{
- QFETCH(QByteArray, in);
-
- QByteArray res;
- res = ::qUncompress(in);
- QCOMPARE(res, QByteArray());
-
- res = ::qUncompress(in + "blah");
- QCOMPARE(res, QByteArray());
-}
-
-void tst_QByteArray::qUncompress4GiBPlus()
-{
- // after three rounds, this decompresses to 4GiB + 1 'X' bytes:
- constexpr uchar compressed_3x[] = {
- 0x00, 0x00, 0x1a, 0x76, 0x78, 0x9c, 0x63, 0xb0, 0xdf, 0xb4, 0xad, 0x62,
- 0xce, 0xdb, 0x3b, 0x0b, 0xf3, 0x26, 0x27, 0x4a, 0xb4, 0x3d, 0x34, 0x5b,
- 0xed, 0xb4, 0x41, 0xf1, 0xc0, 0x99, 0x2f, 0x02, 0x05, 0x67, 0x26, 0x88,
- 0x6c, 0x66, 0x71, 0x34, 0x62, 0x9c, 0x75, 0x26, 0xb1, 0xa0, 0xe5, 0xcc,
- 0xda, 0x94, 0x83, 0xc9, 0x05, 0x73, 0x0e, 0x3c, 0x39, 0xc2, 0xc7, 0xd0,
- 0xae, 0x38, 0x53, 0x7b, 0x87, 0xdc, 0x01, 0x91, 0x45, 0x59, 0x4f, 0xda,
- 0xbf, 0xca, 0xcc, 0x52, 0xdb, 0xbb, 0xde, 0xbb, 0xf6, 0xd3, 0x55, 0xff,
- 0x7d, 0x77, 0x0e, 0x1b, 0xf0, 0xa4, 0xdf, 0xcf, 0xdb, 0x5f, 0x2f, 0xf5,
- 0xd7, 0x7c, 0xfe, 0xbf, 0x3f, 0xbf, 0x3f, 0x9d, 0x7c, 0xda, 0x2c, 0xc8,
- 0xc0, 0xc0, 0xb0, 0xe1, 0xf1, 0xb3, 0xfd, 0xfa, 0xdf, 0x8e, 0x7d, 0xef,
- 0x7f, 0xb9, 0xc1, 0xc2, 0xae, 0x92, 0x19, 0x28, 0xf2, 0x66, 0xd7, 0xe5,
- 0xbf, 0xed, 0x93, 0xbf, 0x6a, 0x14, 0x7c, 0xff, 0xf6, 0xe1, 0xe8, 0xb6,
- 0x7e, 0x46, 0xa0, 0x90, 0xd9, 0xbb, 0xcf, 0x9f, 0x17, 0x37, 0x7f, 0xe5,
- 0x6f, 0xb4, 0x7f, 0xfe, 0x5e, 0xfd, 0xb6, 0x1d, 0x1b, 0x50, 0xe8, 0xc6,
- 0x8e, 0xe3, 0xab, 0x9f, 0xe6, 0xec, 0x65, 0xfd, 0x23, 0xb1, 0x4e, 0x7e,
- 0xef, 0xbd, 0x6f, 0xa6, 0x40, 0xa1, 0x03, 0xc7, 0xfe, 0x0a, 0xf1, 0x00,
- 0xe9, 0x06, 0x91, 0x83, 0x40, 0x92, 0x21, 0x43, 0x10, 0xcc, 0x11, 0x03,
- 0x73, 0x3a, 0x90, 0x39, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32,
- 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32,
- 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32,
- 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32,
- 0xa3, 0x32, 0xa3, 0x32, 0xa3, 0x32, 0x34, 0x90, 0x99, 0xb6, 0x7e, 0xf5,
- 0xd3, 0xe9, 0xbf, 0x35, 0x13, 0xca, 0x8c, 0x75, 0xec, 0xec, 0xa4, 0x2f,
- 0x7e, 0x2d, 0xf9, 0xf3, 0xf0, 0xee, 0xea, 0xd5, 0xf5, 0xd3, 0x14, 0x57,
- 0x06, 0x00, 0x00, 0xb9, 0x1e, 0x35, 0xce
- };
-
- constexpr qint64 GiB = 1024LL * 1024 * 1024;
-
- if constexpr (sizeof(qsizetype) == sizeof(int)) {
- QSKIP("This is a 64-bit-only test.");
- } else {
-
- // 1st
- auto c = ::qUncompress(std::data(compressed_3x), q20::ssize(compressed_3x));
- QVERIFY(!c.isNull()); // check for decompression error
-
- // 2nd
- c = ::qUncompress(c);
- QVERIFY(!c.isNull());
-
- // 3rd
- try {
- c = ::qUncompress(c);
- if (c.isNull()) // this step (~18MiB -> 4GiB) might have run out of memory
- QSKIP("Failed to allocate enough memory.");
- } catch (const std::bad_alloc &) {
- QSKIP("Failed to allocate enough memory.");
- }
-
- QCOMPARE(c.size(), 4 * GiB + 1);
- QCOMPARE(std::string_view{c}.find_first_not_of('X'),
- std::string_view::npos);
-
- // re-compress once
- // (produces 18MiB, we shouldn't use much more than that in allocated capacity)
- c = ::qCompress(c);
- QVERIFY(!c.isNull());
-
- // and un-compress again, to make sure compression worked (we
- // can't compare with compressed_3x, because zlib may change):
- c = ::qUncompress(c);
-
- QCOMPARE(c.size(), 4 * GiB + 1);
- QCOMPARE(std::string_view{c}.find_first_not_of('X'),
- std::string_view::npos);
- }
-}
-
-void tst_QByteArray::qCompressionZeroTermination()
-{
- QByteArray s = "Hello, I'm a string.";
- QByteArray ba = ::qUncompress(::qCompress(s));
- QCOMPARE(ba.data()[ba.size()], '\0');
- QCOMPARE(ba, s);
-}
-#endif
void tst_QByteArray::constByteArray()
{
@@ -657,45 +497,6 @@ void tst_QByteArray::base64()
QCOMPARE(arr64, base64urlnoequals);
}
-void tst_QByteArray::base64_2GiB()
-{
-#ifdef Q_OS_ANDROID
- QSKIP("Android kills the test when using too much memory");
-#endif
- if constexpr (sizeof(qsizetype) > sizeof(int)) {
- try {
- constexpr qint64 GiB = 1024 * 1024 * 1024;
- static_assert((2 * GiB + 1) % 3 == 0);
- const char inputChar = '\0'; // all-NULs encode as
- const char outputChar = 'A'; // all-'A's
- const qint64 inputSize = 2 * GiB + 1;
- const qint64 outputSize = inputSize / 3 * 4;
- const auto sv = [](const QByteArray &ba) {
- return std::string_view{ba.data(), size_t(ba.size())};
- };
- QByteArray output;
- {
- const QByteArray input(inputSize, inputChar);
- output = input.toBase64();
- QCOMPARE(output.size(), outputSize);
- QCOMPARE(sv(output).find_first_not_of(outputChar),
- std::string_view::npos);
- }
- {
- auto r = QByteArray::fromBase64Encoding(output);
- QCOMPARE_EQ(r.decodingStatus, QByteArray::Base64DecodingStatus::Ok);
- QCOMPARE(r.decoded.size(), inputSize);
- QCOMPARE(sv(r.decoded).find_first_not_of(inputChar),
- std::string_view::npos);
- }
- } catch (const std::bad_alloc &) {
- QSKIP("Could not allocate enough RAM.");
- }
- } else {
- QSKIP("This is a 64-bit only test");
- }
-}
-
//different from the previous test as the input are invalid
void tst_QByteArray::fromBase64_data()
{