# Protocol level response

# Introduction

These responses are handled by the communication protocol that is used when connecting to different endpoints (servers hosting a specific protocol). The responses may inform the calling client that the communcation or delivery to a given endpoint was successful or not and may contain details about issues that are relevant such as why a delivery was not successful.

The key nature of these responses is that they do not and should not in any way act on result of validation or processing of the content of the payload that is being sent.

These response messages are commonly called “acks” or referred to as protocol level responses and are different depending on the communication protocol that is used. Please see some examples below.


# AS2 MDN

MDN (Message Disposition Notification) is an electronic acknowledgement of reception that is sent to the sender via AS2 after an electronic message has been sent.

This acknowledgement of reception confirms that the transfer of the AS2 message has been successfully completed and that the message arrived at the desired recipient without changes.

# Example

AS2 MDN example
Date: ons, 06 okt. 2021 15:07:48 +0000
From: support@pagero.com
Message-ID: <OPENAS2-05102092250748+0000-4980@TESTAS2IDFROM_TESTAS2IDTO>
Subject: Your Requested MDN Response
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
boundary="----=_Part_152917_1822765463.1633532868063"
AS2-To: TESTAS2IDTO
AS2-From: TESTAS2IDFROM
AS2-Version: 1.1
Server: Pagero AS2 v1.0
Content-Length: 3724

------=_Part_152915_474541331.1633532868062
Content-Type: text/plain

The message sent to Recipient TESTAS2IDFROM on 2021-10-06T15:07:47.996Z with Subject AS2 Message has 
been received, the EDI Interchange was successfully decrypted and it's integrity was 
verified. In addition, the sender of the message, Sender TESTAS2IDTO at Location 
0.0.0.0 was authenticated as the originator of the message. There is no guarantee 
however that the EDI Interchange was syntactically correct, or was received by the 
EDI application/translator.

------=_Part_152915_474541331.1633532868062
Content-Type: message/disposition-notification

Reporting-UA: Pagero AS2 v1.0@172.17.0.14:10080
Original-Recipient: rfc822; TESTAS2IDFROM
Final-Recipient: rfc822; TESTAS2IDFROM
Original-Message-ID: <SomeOriginalMessageId@TESTAS2IDFROM>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: X9nhLCi0uATGhtC4zMmxeDFdHmL+z92C60ocJRGVuIM=, sha256

------=_Part_152915_474541331.1633532868062--

See IETF RFC3798 for more information.


# HTTP response

For every HTTP request, a HTTP response is (should be) returned. This response includes a HTTP status-code, which is a three-digit integer code giving the result of the attempt to understand and satisfy the request.

The first digit of the status-code defines the class of response. There are five allowed values for the first digit:

HTTP status code Categorization Description
1xx Informational The request was received, continuing process.
2xx Successful The request was successfully received, understood, and accepted.
3xx Redirection Further action needs to be taken in order to complete the request.
4xx Client error The request contains bad syntax or cannot be fulfilled.
5xx Server error The server failed to fulfill an apparently valid request.

The last two digits do not have any categorization role.

# Examples

Successful/positive HTTP response example
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Unsuccessful/negative HTTP response example
HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed

See MDN HTTP messages and/or IETF RFC7231 for more information.