Since there is a newline after the HTTP headers, the only alternative I'm aware of is using a re-search-forward:
(delete-region (point) (point-min))
A higher-level alternative to using url-http-end-of-headers, but equally undocumented, is url-insert-file-contents:
(json-parse-buffer :object-type 'alist))
or equivalently, prior to Emacs 27 compiled with native JSON support:
You might be thinking about impatient-mode, which is available in MELPA, and also on GitHub. I haven't tried it myself, but according to Sacha Chua's blog post about it it seems to be easy to use:
Install the impatient-mode package.
Call M-x httpd-start.
Configure the firewall to allow incoming connections.
Put the selected buffer into impatient-...
With respect to a "proper API", I think the short answer, at present, is "no" -- unless you are willing to rely on an external library. url-http-end-of-headers seems to be as good as it gets, although it isn't mentioned in the URL Programmer's Manual nor does it appear to be documented in emacs source.
In the current version, if you make sure that each of your requests has a comment line immediately succeeding it, then the forms will be passed correctly.
For example, the following code will send 'data':'foobar', with no extra newline. The content length received by netcat is exactly 11, which was what we wanted.
,----[ C-h f url-handler-mode RET ]
| url-handler-mode is an interactive autoloaded compiled Lisp function
| in `url-handlers.el'.
| (url-handler-mode &optional ARG)
| Toggle using `url' library for URL filenames (URL Handler mode).
This problem was solved by forcing emacs to use https instead of http. For some reason, emacs is using http as default instead of https.
Steps to solve:
(customize-variable RET package-archives)
changed http to https in url fields
I wonder why emacs would use http as a default?...
I believe that Emacs 26.3 fixes this.
You should upgrade (26.2 to 26.3 is a very minor update; nothing should break); but if you genuinely cannot do that for some reason, then this might do the trick for you:
(setq gnutls-algorithm-priority "NORMAL:-...
Whenever an Emacs user receives an error message like void-function request, it generally means the function has not yet been defined because the library containing that function has not been loaded. If, for example, the function at issue is named request and it is defined in the library request.el, then before using the library, evaluate the following ...
When in doubt, simplify. Start your Emacs with emacs -Q to disable initialization. Then in the *scratch* buffer, evaluate the following lines by hitting Ctrl+j after each lisp line. Afterwards your *scratch* buffer will look like:
Then do Meta+x list-packages. This will ...
Here is how I would debug this:
First, find the failing bytecode. This ought to be the function on the stack just before the call to error. In this case it seems to be open-network-stream.
Disassemble this method using disassemble. In order to understand this you may need to read through bytecode.c a bit, or maybe the bytecode compiler, depending on ...