Does http_post/4 supports HTTPS URLs?

Help!
1

Hi,

I’m using the latest swipl-devel git version and trying to use http_post/4 with a HTTPS URL. Where these supported? All my attempts so far result in:

url 'https://...'' does not exist (status(400,Bad Request)).

Any incantation I missed?

Thanks,
Paulo

2

Should work fine. The message suggests the request is wrong, which may mean just about anything. Do GET requests work? If so, there is nothing wrong with the TLS setup and the problem is probably with the data format

3

Hi Jan,

Thanks for the quick reply. I’m making the same request successfully using the macOS Rested application, which allows the same parameterization of the POST request:

http_post('https://...', atom(Body), Reply, [header('Content-Type','application/x-www-form-urlencoded')]).

Body is the same payload I use in Rested. I was wondering about HTTPS support due to:

ERROR: [14] throw(error(existence_error(url,'https://...'),context(_952,...)))

The URL is correct, no typos there. I will continue debugging. Thanks for the tips.

Cheers,
Paulo

4

header('Content-Type','application/x-www-form-urlencoded') is most likely wrong. This will only succeed if the server responds with this header. You can use request_header (check), or better use form(Attributes) instead of atom(Body).

5

I will try some variants as you suggest. The parameterization that I’m using is required by the web service I’m accessing.

6

Made progress. I now receive the expected answer from the web service but with a warning:

Warning: Domain error: 'set_cookie' expected, found ''...''. (an atom)

This happens with library(http/http_cookie) loaded (not sure is required as I’m only using the HTTP client libraries). It sounds like the cookie provided by the web service is not being correctly handled by the code expected to save it?

7

Using library(http/http_cookie) is mostly intended for clients AFAIK. It scans replies for cookies and maintains a database thereof, applying the proper cookie to the next request. It is typically needed if some form of cookie based login is used by the site. There are also sites that redirect to themselves with a cookie on the first interaction and even get into a loop if you do not pass this cookie in the next request.

The warning simply suggests that the cookie doesn’t parse according to the HTTP cookie syntax. That may of course be an error in the library, but sites sending illegal cookies are not uncommon :frowning: