ASHNET.DLL

This dynamic link library (Windows only) contains support routines for various network-related functions, in particular:

• HTTP.SBR

• PDFX Email Type 4

• CRYPTO.SBR

 

Update Notes, 2016 November, version 1.8.153, 54

Relink with updated SSL, SFTP and HTTP libraries to incorporate many minor bug fixes and improvements in the underlying libraries over the last 11 months. The DLL is backwards compatible to A-Shell and ATE 6.2.

The properties options introduced in 1.8.153 now apply to the HTTPF_REQGET ("simple get") operation as well as the other operations/modes; previously they were ignored for the simple get. Also, the default timeout parameters (30 seconds on connection, 75 on read) now apply to the HTTPF_REQGET operation even if properties are not explicitly specified. Previously the timeouts were indeterminate, but definitely shorter than the new defaults.

Update Notes, 2014 May, version 1.7.145

Security-related enhancement:

• supports public/private key authentication for SFTP via AG_FTP or FTPDLX.

• fixes problems with SFTP downloads without explicit local paths.

• fixes a bug in CRYPTO.SBR where the dst parameter was being truncated if needed to allow for an explicit trailing null.

• supports new CRYPTO.SBR function to generate public/private key files.

Note: requires ASHW32.EXE 6.1.1385.0+ and should be updated at same time.

Update Notes, 2013 July, version 1.4.137

• Implements support for initial functionality of CRYPTO.SBR

Update Notes, 2013 June, version 1.4.135

• Support new HTTP.SBR arguments certfile and certpw

Update Notes: 2012 October/November, version 1.4.132

• User agent in headers now shows "ashnet 1.4.131."

• Now accepts port specifications embedded in the URL, i.e. http://www.mydomain.com:10080/mypath. Previously it only accepted the port if it was appended to the end of the URL, but that is a non-standard syntax and results in the port not being included in the "Host: domain{:port}" header of a POST request. The syntax shown above, i.e. {scheme}<domain>{:port}{path} is preferable.

• The DEBUG.REQ file (copy of the request) had an extra CR at the end of each line (CRCRLF instead of CRLF). This didn't affect the actual request, but may have confused tech support efforts.

• When the XHTTPF_DEBUG flag is set, in addition to creating the DEBUG.REQ file, it also appends a line to ASHNET.LOG indicating the ashnet.dll version, domain, port, SSL flag and return status, e.g.:

HttpRequest v127 to www.mydomain.com port 10080 (SSL) rc=201 HTTP/1.1 201 created

This serves mainly to eliminate doubts during debugging as to where and how the request (DEBUG.REQ) was sent.

In addition, a new log file, DEBUG.LOG, will be created that combines lower level details about the individual steps performed within the operation, but also a transcript of what is sent and received over the wire.

• Support custom Content-Type prefixes for uploaded files using XHTTPF_REQUPLOAD

• Support separate option to retrieve the HTTP status text using XHTTPF_GETSTSTXT

• If the operation fails to connect to the server, a verbose log of the request details is now written to the file DEBUG.LE (e.g. LastError), which might be helpful in debugging.

• Added XHTTPF_REQGETRAW: like XHTTPF_REQGET (&h0020) but works around a limitation of XHTTPF_REQGET in which certain characters outside the range supported by Latin1/ANSI (e.g. Russian or Chinese) would just be dropped from the response. Can also be used to retrieve binary data containing embedded nulls (such as a file), although you must then use XHTTPF_FILERESP (&h0200) to write the response to a file.