Releases: Dyalog/HttpCommand
v5.1.13
Fix #11 HTTP Basic authentication casing
Fixes #11
While the Basic authentication scheme name is supposed to be case insensitive per RFC7617, it seems some deficient servers require it to be 'Basic'. This release ensures that if HttpCommand injects the Basic scheme name it is always 'Basic'.
This change should not have any effect on existing uses of HttpCommand.
v5.1.11 - workaround for Conga long URL issue
Fixes #10
Conga's HTTP mode allows sending requests in two formats:
- as a CRLF-delimited character vector
- as a nested vector of method, uri, HTTP version, headers, payload
If using the nested form, which HttpCommand has done since v4.0, Conga can wrongly signal a 1081 error if the URL is longer than roughly 4096 characters. Conga v3.5 (to be released with Dyalog v19.0) has been updated to address this. Rather than backport this fix to earlier Conga versions and force people to upgrade their Conga shared libraries, we have implemented a change to HttpCommand to resend the request as a character vector if sending it in nested form fails with a 1081 error.
This change should only affect people who send requests with very long URLs.
Fix early exit on HTTPError event
The change made in v5.1.9 (to accommodate somewhat deficient servers like Jetty) exited too early meaning that the decoding of known content-encoding schemes (like gzip) was skipped over. This release fixes that.
Similar to v5.1.9:
- it's unlikely that anyone other than Jetty users will ever encounter this
- Conga v3.5 is necessary this specific fix to work. However, for the vast majority of users, the installed version of Conga should work just fine.
Fix Issue #8 (OutFile Broken)
This release fixes issues #8.
An error would occur when OutFile was specified as a file name, as opposed to a folder name.
v5.1.8
Receive payload even with no content-length nor transfer-encoding
This change is unlikely to affect any users other than those seeking to communicate with "Jetty" (the web server for Jenkins). This change requires Conga v3.5 or later to be effective. If you're not communicating with Jetty, your current Conga version should be just fine.
For at least some requests, Jetty does not compute the content-length of the response payload (so there's no content-length header). Nor does it send the response payload using "chunked" transfer encoding. Instead it just regurgitates the entire payload and a "connection: close" header. This means the client (HttpCommand) may receive multiple HTTPBody events. Previous behavior considered the response to be complete upon the receipt of an HTTPBody event. If there's no content-length header, and there is a "connection: close" header, v5.1.7 will continue to process subsequent HTTPBody events until the entire payload is received.