mirror of
https://github.com/AdaCore/aws.git
synced 2026-02-12 12:29:46 -08:00
e97f27078a
On PPC systems, HTTP2 & HPACK testcases were failing because
AWS.HTTP2.HPACK.Huffman.Decode was raising Protocol_Errors over inconsistent
padding.
The encoded bytestrings were correct; things were diverging in
AWS.HTTP2.HPACK.Decode, where bytes were misinterpreted when read as
RFC_Byte, due to that record's representation clause being target-dependent.
For example, if we break in that function right as it processes the first
byte of an encoded string, and that first byte is decimal integer 130…
256 Byte := Get_Byte;
(gdb) next
258 if Bit.B0 = 1 then
(gdb) p/t byte
$8 = 10000010
In RFC_Byte's "Bₙ at 0 range i .. j" component clauses, by default, i and j
are interpreted differently depending on which bit ordering the target uses.
Thus on a little-endian platform like x86_64-linux:
(gdb) p/t bit
$9 = (
b7 => 0,
b6 => 1,
b5 => 0,
b4 => 0,
b3 => 0,
b2 => 0,
b1 => 0,
b0 => 1,
b23 => 10,
b22 => 0,
b21 => 0,
b20 => 10,
b30 => 100,
b41 => 10,
b40 => 1000
)
Whereas on a big-endian platform such as ppc64-linux:
(gdb) p/t bit
$9 = (
b7 => 1,
b6 => 0,
b5 => 0,
b4 => 0,
b3 => 0,
b2 => 0,
b1 => 1,
b0 => 0,
b23 => 10,
b22 => 0,
b21 => 0,
b20 => 10,
b30 => 10,
b41 => 1000,
b40 => 10
)
Fix this by picking an explicit Bit_Order for RFC_Byte, so that in those
range clauses, i and j are interpreted consistently across all platforms
(i.e. pick Low_Order_First so that "0" refers to the MSb, "7" to the LSb).
Also fix AWS.HTTP2.HPACK.Huffman.Decode, which presents a similar problem: a
Stream_Element is aliased as an array of bits, but the indexing order of that
array will depend on endianness. Use a similar solution to
2023-03-21 "Fix creation of Huffman decoding tree for big-endian
platforms" (7eca5a10c)
That is, remove the aliasing array type, and rely on platform-independent
shifts.
TN: eng/toolchain/aws#4
A W S - Ada Web Server
20.0 release
Authors:
Dmitriy Anisimkov
Pascal Obry
AWS stand for Ada Web Server. It is a small yet powerful HTTP component to
embed in any applications. It means that you can communicate with your
application using a standard Web browser and this without the need for a Web
Server. AWS is fully developed in Ada with GNAT.
AWS support SOAP/WSDL, Server Push, HTTPS/SSL, client HTTP, hotplug
modules...
AWS comes with SOAP/WSDL support, two tools are proposed:
ada2wsdl which generates a WSDL document from an Ada spec
wsdl2aws which generates stubs/skeletons AWS code from a WSDL document
Both tools have mapping for standard Ada types but also supports Ada
enumerations, character, records and arrays.
The SOAP implementation has been validated on http://validator.soapware.org/.
This on-line service is not available anymore but the current implementation
is validated against the Apache/AXIS SOAP implementation to ensure the
interoperability. Some users have also reported to have used AWS/SOAP with
.NET and gSOAP without trouble.
Non upward compatible changes
-----------------------------
Note that the changes listed below can introduce non upward compatibility.
In such a case we try to give proper advice on how to change the code
to work properly. Of course we try to avoid this as much as possible
but we really prefer to have a clean API instead of keeping awkward
implementations.
- To support SMTP secure STARTTLS switching protocol the parameter to
SMTP.Initialize has been changed from Secure to Security and
instead of a boolean it takes a Secure_Connection enumeration which
can be No, TLS or STARTTLS.
If Secure was set to False, Security must be No.
If Secure was set to True, Security should probably be TLS except if
the STARTTLS swicthing protocol is to be used.
Obsolescent features
--------------------
In each new version we try to be upward compatible with previous
version. This is really important, but in some cases it seems that a
"redesign" of the API would be good in the long term. All obsolescent
features will be listed in this section. Those features will be
removed in the next version. Note that you can check usage of those
features in your application by using the GNAT's -gnatwj option as we
have tagged all obsolescent features with a pragma.
Pointers
--------
AWS Home Page (sources and printable documentations in Postscript and PDF):
http://libre.adacore.com/tools/aws
Templates_Parser sources:
Templates_Parser module (sources and documentation) is provided with AWS
distribution.
GNU/Ada - GNAT
You need at least GNAT 2015 GPL Edition or GNAT Pro 7.2
http://libre.adacore.com/tools/gnat-gpl-edition/
XML/Ada (optional):
You need this library only if you want to use AWS SOAP feature. You need
at least XML/Ada version 2.2.0.
http://libre.adacore.com/
OpenSSL (optional):
You need to install manually the development libraries (>= 1.0.2).
LibreSSL (optional):
You need to install manually the development libraries (>= 2.8.0).
LibreSSL is an implementation fully compatible with OpenSSL, you
just have to configure AWS as with OpenSSL.
GNUTLS (optional):
You need to install manually the development libraries. AWS needs at
least version 3.2.4 of GNUTLS.
OpenLDAP library (optional) :
Sources for UNIX or Win32:
http://www.openldap.org/
Win32:
AWS binding will use to the Microsoft LDAP dynamic library.
Windows Services API (optional):
To build the runme demo as a Windows NT/2000 services you must download
the services API made by Ted Dennison for his SETI@Home project.
http://www.telepath.com/~dennison/Ted/SETI/SETI_Service.html
Reporting bugs
--------------
You can report bugs to AdaCore: report@adacore.com
Contributors
------------
Thanks to the contributors and peoples who send feedbacks, ideas
about AWS. In the early stage of the project this is very valuable.
So thanks goes to Georg Bauhaus, Ted Dennison, Wiljan Derks, Sune Falck,
David C. Hoos, Audran Le Baron, Thierry Lelegard, Nicolas Lesbats,
Olivier Ramonat, Jean-François Rameau, Maxim Reznik, Jean-Pierre Rosen,
Jerme Roussel, Ariane Sinibardy, Henrik Sundberg.
Thanks to all who have reported bugs and have sent us patches.