branch: externals/plz
commit 7478d43668c916c71f2fa87560136031d55025c9
Author: Adam Porter <a...@alphapapa.net>
Commit: Adam Porter <a...@alphapapa.net>
Revert "Add/Change: Handle LF-only HTTP responses"
This reverts commit 8d2654bba7bfa11525aef50f969c489c20ac0a43.
The problem was not the line endings in the server's response, but
that I wasn't aware that curl was implicitly sending an "Expect"
header, causing the server to return an additional "HTTP 100 Continue"
response. See <https://gms.tf/when-curl-sends-100-continue.html>. In
the next commit, we tell curl to omit that header, so the server
doesn't do that, and we only parse one response.
---
plz.el | 36 +++++-------------------------------
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/plz.el b/plz.el
index 9734c4c454..30f4737369 100644
--- a/plz.el
+++ b/plz.el
@@ -559,9 +559,7 @@ according to the apparent coding system."
(save-excursion
(goto-char (point-min))
;; Parse HTTP version and status code.
- (unless (looking-at plz-http-response-status-line-regexp)
- (error "Unable to parse HTTP response status line: %S"
- (substring-no-properties (buffer-string))))
+ (looking-at plz-http-response-status-line-regexp)
(let* ((http-version (string-to-number (match-string 1)))
(status-code (string-to-number (match-string 2)))
(headers (plz--headers))
@@ -586,14 +584,10 @@ refer to rather than the current buffer's unparsed
headers."
(defun plz--http-status ()
"Return HTTP status code for HTTP response in current buffer."
- ;; This function is used in the sentinel to get the HTTP response
- ;; code without parsing the whole response.
(save-excursion
(goto-char (point-min))
- (unless (looking-at plz-http-response-status-line-regexp)
- (error "Unable to parse HTTP response status line: %S"
- (substring-no-properties (buffer-string))))
- (string-to-number (match-string 2))))
+ (when (looking-at plz-http-response-status-line-regexp)
+ (string-to-number (match-string 2)))))
(defun plz--headers ()
"Return headers alist for HTTP response in current buffer."
@@ -601,7 +595,7 @@ refer to rather than the current buffer's unparsed headers."
(goto-char (point-min))
(forward-line 1)
(let ((limit (save-excursion
- (plz--skip-headers)
+ (re-search-forward "^\r\n" nil)
(point))))
(cl-loop while (re-search-forward (rx bol (group (1+ (not (in ":"))))
":" (1+ blank)
(group (1+ (not (in "\r\n")))))
@@ -613,30 +607,10 @@ refer to rather than the current buffer's unparsed
headers."
;; use `alist-get' without having to add "nil nil #'equal"
every time.
collect (cons (intern (downcase (match-string 1)))
(match-string 2))))))
-(defun plz--skip-headers ()
- "Move point past headers in current HTTP response buffer.
-It seems that some misbehaving HTTP servers use only LF line
-endings rather than the RFC 2616-mandated CRLF endings, so we
-must try to handle either."
- ;; It seems that this is happening with some Cloudflare responses. :(
- ;; NOTE: For debugging purposes, I'm inserting these warnings for now. If
this is a solvable
- ;; bug, or if I come to understand the issue better, they could be removed
or disabled.
- (condition-case _err
- (re-search-forward "^\r\n" nil)
- (search-failed ;; Try LF-only.
- (condition-case _err
- (progn
- (re-search-forward "^\n" nil)
- (display-warning 'plz (format "Only LF used after headers in HTTP
response: %S"
- (substring-no-properties
(buffer-string)))))
- (search-failed
- (signal 'search-failed (format "Can't find end-of-headers in HTTP
response: %S"
- (substring-no-properties
(buffer-string)))))))))
-
(defun plz--narrow-to-body ()
"Narrow to body of HTTP response in current buffer."
(goto-char (point-min))
- (plz--skip-headers)
+ (re-search-forward "^\r\n" nil)
(narrow-to-region (point) (point-max)))
;;;; Footer
