dyalog / httpcommand Goto Github PK

On an request that can take a payload (anything but HEAD and GET), allow the user to specify to use either gzip or deflate compression.

Currently one needs to compose the request body and boundary when using content-type multipart/form-data. HttpCommand should be able to generate a boundary on the fly and populate the body. Use the curl standard for embedding files when there is a file= element by doing an upload when the file name is prefixed by '@' and just embedding the octet-stream when the file name is preceded by '<'.

If I have a header field where the value contains two % signs then the part between the % signs are removed.

HttpCommand.Get 'http://localhost:8081' '' ('klyp' 'klyp%test%kage')

ends up as
klyp klypkage

On the server.
This did not happen in version 5.4.6 but does happen in version 5.6.0

It appears that the folder is not the basis for the documentation, but if that is so, then the documentation appears not to be part of the project which would not be ideal.

Maybe the README should say something about this, and how to contribute to the documentation.

https://dyalog.github.io/HttpCommand/operational-settings/#timeout links to https://dyalog.github.io/HttpCommand/operational-settings/conga-settings.md#waittime but it should be to https://dyalog.github.io/HttpCommand/conga-settings/#waittime

If you attempt to send a request with a URL that is 4K or longer, Conga signals a 1081 error which HttpCommand subsequently reports.

I suggest to change the file extension to .aplc

This is not a bug in HttpCommand, but rather in the server it tries to connect to (I think). HttpCommand sends the AuthType (basic in my case) in lowercase which I believe should be ok, but the problem is that the server doesn't recognize it.
Googling the issue I can see others hitting same issue. I suspect many server implementations require the auth-scheme to match case exactly, so expect Basic or Bearer etc.

I can work around the issue, but as casing makes no difference to the client, consider changing to use the "expected" casing.

Hi, should the date in

An HTTP HEAD command does essentially the same as a GET except that it just returns the headers from the host without any payload. Also, in the case where the response payload is empty, no processing should be attempted.

This is caused by the Result space being created in the root and therefore inherits ⎕IO ⎕ML from it. GetHeader assumes ⎕IO=1 and ⎕ML=1.

Currently, a successful GetJSON request tells you "⍴Data: ⍬". It would be less confusing if it said something like "Data: Namespace {msg, payload}" or if the list is long "Data: Namespace {17 names}".

When accessing a web service with multiple requests, BaseURL can be set to the common root of the URLs. For example:

h←HttpCommand.New 'get'
h.BaseURL←'https://api.github.com/'
h.URL←'orgs/myorg/repos'

Will issue the request to https://api.github.com/orgs/myorg/repos

h.URL←'repos/myorg/myrepo/commits'

Will subsequently issue a request to https://api.github.com/repos/myorg/myrepo/commits

Currently HttpCommand will UTF-8 decode the response payload only if the 'content-type' header contains 'charset=utf-8'. However, the default charset for the application/json MIME type is UTF-8,

HttpCommand should UTF-8 decode the response payload if the content-type MIME type is application/json and charset is not specified or if charset=utf-8 is specified, regardless of MIME type.

Current check doesn't recognize a valid instance of LIB. Would need to use

¯3.1=CongaRef.⎕NC⊂'Clt'

or better yet check the class

'.LIB'¯4↑⍕⊃⊃⎕CLASS CongaRef

Specifying a file, as opposed to a folder, for OutFile is broken.

If all of the below are true:

• Timeout is set to a negative number which means don't time out as long as HttpCommand is receiving data.
• WaitTime < 1000 × |Timeout ⍝ WaitTime is in milliseconds and Timeout is in seconds
• The server doesn't send anything before WaitTime expires

Then you'll get a RANK ERROR in checkTimeOut

Note: in the migration from HttpCommand v4 to v5, we swapped the meanings of the Timeout and WaitTime settings. This applies issue HttpCommand v5.

HttpCommand will issue a "No URL specified" error if the URL setting is empty. When we implemented the BaseURL setting, in order to make it more convenient to make repeated calls to different endpoints of the same host, the final URL for request is comprised of the concatenation of BaseURL and URL. However, that concatenation isn't performed until after the check for an empty URL is performed. The concatenation should be done prior to the check for an empty URL.

19.0.47901 classic (tried WIndows and AIX)
]load HttpCommand
#.HttpCommand
HttpCommand.Version
HttpCommand 5.4.0 2023-09-06
⍴(HttpCommand.Get'www.dyalog.com').Data
0

is fine with Unicode

Was fine in 18.2 with 4.0.14 for example (and I think was ok in versions of HttpCommand shipped with earlier 19.0s

Since Timeout needs to be larger than or equal to WaitTime÷1000 then HttpCommand should up the Timeout if the user increases WaitTime. This way, the user only needs to change one value to increase the time given for a response.

HttpCommand creates a few headers in the request it sends.
For instance, accept-encoding is set to 'gzip, deflate'. While you can change the value, you cannot stop HttpCommand from inserting the header unless you use the SuppressHeaders setting which will suppress all HttpCommand-generated headers, but this means you'll need to specify all headers you want for the request.

Previously, setting a header with an empty value would cause HttpCommand to fuss about "invalid header format". However it's probably more useful to simply not include headers that have an empty value set.

The SetHeader, AddHeader, and RemoveHeader methods do not return results which makes their use in dfns a bit awkward. The should return a shy result of the Headers array.

Currently when using the OutFile setting, the response payload is written to file immediately upon receipt, including when using "chunked" transfer-encoding (each chunk is written to file as it is received). If the response is compressed using gzip or deflate content-encoding, the file contains the compressed data. The file should be uncompressed.

819⌶ (case conversion) is scheduled to be deprecated in Dyalog v20.0.
⎕C wasn't introduced in Dyalog until v18.0. Since our tools policy is to support the 3 most recent releases of Dyalog APL (currently 17.1, 18.0 and 18.2). Internal development of v20.0 is now underway and as such HttpCommand needs to support both 819⌶ and ⎕C at least until Dyalog v19.0 is released and v17.1 can drop off the list of "3 most recent releases".

HttpCommand.Upgrade retrieves the latest released copy of itself and attempts to ⎕FIX the payload. The ⎕FIX fails because the source of HttpCommand contains characters not in ⎕AVU. One workaround might be to write the raw payload bytes to a temporary file, then ⎕FIX the file (the offending characters will be translated to something palatable by ⎕FIX), and then delete the temporary file.

No Dyalog Classic user has raised this as an issue, so for now, we'll disable HttpCommand.Upgrade on Classic (returning a descriptive message). If in the future there is user demand for it to work, then we'll revisit the issue.

This is probably a bug in the check:

The question is if this is necessary at all. Is UTF-8 encoding not enough?

An error occurs if DRC is already initialized outside of HttpCommand.

Currently users need to code something like

resp←HttpCommand.Get 'some.url'
:If 0 200≡resp.(rc HttpStatus)
    ⍝ do some processing
:Else
    ⍝ got an error

IsOK will check rc and HttpStatus and return 1 if rc=0 and HttpStatus is a 200-series code so that the above would be recoded as:

resp←HttpCommand.Get 'some.url'
:If resp.IsOK
    ⍝ do some processing
:Else
    ⍝ got an error