Hosted SaaS solution for AS2 and SFTP file transfer. No infrastructure, instant setup.
Start Free Trial
FDA
What Is AS2 Restart in 2026? How It Works & Why It Matters
Discover how AS2 Restart reduces transmission failures for very large files by restarting failed transfers from the point of failure, not the beginning.
Udith Gunaratna
Modified: 20 Apr 2026
AS2 file transfer protocol defined by RFC 4130 is a secure file exchange protocol, widely used for business-to-business data exchange. Its key features such as end-to-end encryption, digital signatures and non-repudiation have made this protocol popular within many industries including retail (Walmart, Amazon, Target etc.), health (FDA, EMA) and logistics.
Read more: AS2 Protocol
Background
Since AS2 transmission operates on top of HTTP protocol, it is also vulnerable to the usual HTTP related transmission failures such as connection timeouts, socket timeouts, etc. But unlike plain HTTP, AS2 protocol’s features make it possible to clearly identify almost all transmission failure scenarios, so the transmission can be retried. In most cases where AS2 is in use, the sizes of the files being exchanged are fairly small, usually in kilobyte (kB) range or a few Megabytes (MBs) at most. In such scenarios, it is possible to re-transmit the whole file again when a transmission failure was identified. But in some cases, specially in the pharmaceutical domain, AS2 protocol is used to exchange very large files that can be even hundreds of GigaBytes (GBs) in size. Due to the size of the file and the longer time it takes to transmit such files over the public internet, the possibility of transmission failures increases. In such a scenario, re-transmitting the whole file again is not favorable, as it can result in the same failure again and also the network congestion and data transmission costs would be significant due to these re-transmissions.
Read more: Custom HTTP Header Profiles in AS2 Communication
AS2 Restart
As a solution to the above issue, a new Internet Draft Document named as AS2 Restart for Very Large Messages was submitted. This introduced a mechanism to restart any failed transmissions from the point of failure instead of re-transmitting the whole file. This mechanism utilizes the already existing HTTP headers for this purpose and, because of that any AS2 software which implements this will be compatible even with any other AS2 software that does not support AS2 restart.
From this point onwards, the terms AS2 client or client refers to the AS2 software that is sending the file, and the terms AS2 server or server refers to the AS2 software that is receiving the file. Also the term file refers to the content transferred over HTTP, after encrypting and/or signing the original file based on the trading partner’s AS2 configuration.
Read more: AS2 Retry Settings for Failed & Incomplete Messages
HTTP Headers
In addition to the usual AS2 related headers, this mechanism utilizes the following two additional HTTP headers for its purpose.
Etag- The AS2 client will use this header to specify a Transfer ID associated with this transmission. The client must guarantee that the value of this transfer ID adheres to the following conditions, and any re-transmission attempts of the same file should contain the same Transfer ID.- A particular Transfer ID should refer to only one specific file.
- Transfer ID must be unique across any AS2 software, i.e. a transfer ID used by a particular AS2 client should not be used by another.
- Transfer ID must adhere to RFC2616 minus the weak indicator.
In HTTP, typically the hash of the file is used as the
ETag. But since calculating the hash of large files is costly from both time and processing, the client has the freedom to use any other mechanism at its disposal (such as a database ID, timestamp) to generate a valid transfer ID as long as it conforms to the conditions mentioned above.
Content-Range- The AS2 client will use this header to indicate which part of the file (the byte range) is being transferred in the current transmission attempt.
The AS2 server should utilize the values of ETag and Content-Range to temporarily cache the received file until the full file is transmitted, so in case of a failure, a restart of the transmission from the point of failure can be performed.
File Transfer
Usually in AS2 transmissions, a file is transferred via a POST request from the AS2 client to the AS2 server. But in the AS2 restart mechanism, an additional HEAD request is used by the client to query the server on how much content of the file is already received by the server during the previous partial transmissions. Let’s see how this is being used during the initial transmission and during subsequent transmission restart attempts.
Initial Transmission of a new file
- When a new file is required to be transferred, the AS2 client will first generate the unique Transfer ID.
- Then the client will send a
HEADrequest to the AS2 server with the above transfer ID specified as the value ofETagheader. The purpose of this request is to query the server whether the server has already received (at least partially) a file with this transfer ID before, and if yes, how much content has already been received. - Since this is a new file, the server should not have any content with this transfer ID. Therefore,
- if the server supports AS2 restart, it will respond with a
200status and aContent-Lengthheader with value0. The meaning of this response is that the server doesn’t have any content of a file with this transfer ID. - if the server doesn’t support AS2 restart, it will respond with a non 200 status indicating that it didn’t understand the request.
- if the server supports AS2 restart, it will respond with a
- When the client receives any of the above responses, it will attempt to transfer the complete file from the beginning through a
POSTrequest. In addition to the usual AS2 related headers, this request must also contain the sameETagheader sent on the previousHEADrequest. Since this POST request is transferring a new file (or overwriting an existing file), it is not required to send theContent-Rangeheader. - The server should cache the received file content on its system with an association to the received transfer ID, so that the transfer can be restarted from a subsequent attempt if the current attempt fails before completion
Although the RFC states that the
HEADquery should be used even with the initial transmission of a file, some AS2 software do not use it for initial transmissions. Most commonly this is done to prevent the unnecessary delay and network overhead, as the client is aware that this is a fresh transmission, and there is no information to get from the server via theHEADquery.
Re-transmission of a previously failed file
- When a file which has previously failed transmission is required to be restarted, the AS2 client will first re-generate or retrieve the unique Transfer ID which must be the same one used for the initial transmission of this file.
- Then the client will send a
HEADrequest to the AS2 server with the above transfer ID as the value ofETagheader. - Since this file has been attempted to be sent before, the server should have at least partial content with this transfer ID. Therefore, given that the server supports AS2 restart, it will respond with a
200status and aContent-Lengthheader indicating how many bytes of this file has already been received by the server (let’s represent this value byn). - When the client receives the above response, it will restart transmitting the file starting from the next byte
(n+1)through aPOSTrequest. In addition to the usual AS2 related headers, this request must contain the sameETagheader sent on the previousHEADrequest. And most importantly it should also contain theContent-Rangeheader indicating the range of bytes that the client expects to transfer through this request. - The server should append the received content to its already cached partial file under the specified transfer ID, based on the byte range indicated on the
Content-Rangeheader.
If the returned
Content-Lengthvalue from theHEADquery equals the total file size, the client should send at least one byte of data in the nextPOSTrequest.
In summary, when a very large file is sent from an AS2 client to a server (with both supporting AS2 Restart feature), the transmission will be started with an ‘initial request’ as mentioned above, and continued to be re-attempted with one or more ‘restart requests’ until the file is fully received by the server.
Conclusion
Implementing AS2 Restart is about more than just “finishing a transfer”; it’s about building a robust, backwards-compatible infrastructure. By leveraging existing HTTP headers like Range and Content-Range, AS2 Restart provides a sophisticated failover mechanism without breaking compatibility with older systems.
Are you in need of an AS2 solution? Feel free to reach out to us via support@as2gateway.com
Udith is the Chief Technology Officer at Aayu Technologies. With over 9 years of experience in the enterprise software industry, he has been instrumental in architecting, developing, and maintaining a range of enterprise software solutions, particularly B2B communication software, with a significant focus on cloud technologies.
Talk to an EDI Expert
Stay Compliant. Stay Connected. Powered by AS2.
Join hundreds of organizations already taking full control of their B2B AS2 communications with our trusted solutions. Contact us today to tailor a solution that fits your specific AS2 EDI needs.
Request a demo and take a live look at all the features of our AS2 EDI solutions.
Get answers to your questions and explore customizations that we can offer tailored specifically for you.
Get to know the dedicated deployment option available for your specific use cases.
Related Articles
View All BlogsExplore our product stack
Try before you commit. 30 days, no credit card needed
Get full access to whichever product fits your needs. Configure real trading partner connections, run end-to-end transactions, and see the platform perform before making any commitment. All three products include a free 30-day trial with no restrictions.
Driving Innovation, Simplifying Connections.
EDI via AS2
30-day Free Trial
Secure and Compliant
