| • | 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.
| • | XHTTPF_REQUPLOAD now allows you to specify the Content-Type and name attributes associated with each file (using XHTTPF_FILEREQ). To specify the attributes, prepend in front of each filespec in the request parameter the following: |
Content-Type=<type>|<name>=
where <type> may be any content-type string, known or unknown, and <name> is the value of the "name" attribute to be associated with the file. For example:
request$ = "Content-Type=text/html|homepage=c:\temp\mypage.txt"
In the above case, the header associated with the file in the request would look something like:
Content-Disposition: form-data; name="homepage"; filename="mypage.txt"
Content-Type: text/html
As before, you can include multiple files in the request$ string by separating them with semicolons. Any filename which does not start with the "Content-Type" prefix will be treated as before, with the Content-Type being set according to the file extension, and the name attribute set to "file" (,"file2", etc.)
| • | A new flag, XHTTPF_GETSTSTXT (&h00100000) may be used, in a separate XCALL HTTP operation, to retrieve the HTTP status text from the previous call. Normally the numeric status and response body is sufficient, but in some cases, web services may include explanatory text in the HTTP status response header. For example, here we use the XHTTPF_GETSTSTXT call to retrieve the full status text string after receiving a status 400 (malformed request). |
flags = XHTTPF_REQPOST | XHTTPF_FILEREQ | XHTTPF_FILERESP | XHTTPF_SETFROMURL
xcall HTTP, 1, status, flags, url$, request$, response$
if status = 400 then
xcall HTTP, 1, status, XHTTPF_GETSTSTXT, "", "", text$
? text$ ! e.g. "HTTP/1.1 400 Invalid customer ID"
endif
Note that the status text returned here is the same as appears at the end of the ASHNET.LOG line if the XHTTPF_DEBUG flag is set.
| • | 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. |
Note to Ty: go find other references to ashnet.dll
