[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[elpa] externals/plz 7478d43668 51/81: Revert "Add/Change: Handle LF-onl
From: |
ELPA Syncer |
Subject: |
[elpa] externals/plz 7478d43668 51/81: Revert "Add/Change: Handle LF-only HTTP responses" |
Date: |
Wed, 11 May 2022 17:58:01 -0400 (EDT) |
branch: externals/plz
commit 7478d43668c916c71f2fa87560136031d55025c9
Author: Adam Porter <adam@alphapapa.net>
Commit: Adam Porter <adam@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
- [elpa] externals/plz 971077e1d3 23/81: Tests, (continued)
- [elpa] externals/plz 971077e1d3 23/81: Tests, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 30e48b1e6a 22/81: Tidy, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 05f93b0b6b 25/81: Meta: Update Makefile, makem.sh, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 19a0110109 33/81: Notes: Add ToC, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 9a1b119eff 38/81: Meta: Ignore sandbox/, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 0301272d8d 40/81: Add: plz-put, ELPA Syncer, 2022/05/11
- [elpa] externals/plz a5f22b23e1 42/81: Add: (plz), ELPA Syncer, 2022/05/11
- [elpa] externals/plz 430ceffd1d 43/81: Change: Handle killed processes, ELPA Syncer, 2022/05/11
- [elpa] externals/plz f40d3ecbdd 47/81: Add/Change: :noquery argument for make-process, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 1884d038ae 46/81: Notes: Add note about Lars Ingebrigtsen's with-url macro, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 7478d43668 51/81: Revert "Add/Change: Handle LF-only HTTP responses",
ELPA Syncer <=
- [elpa] externals/plz 8d2654bba7 49/81: Add/Change: Handle LF-only HTTP responses, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 220f882ee4 53/81: Tests: (plz-post-jpeg-string) Add, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 4a246e24f6 54/81: Add: Upload binary files, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 7c27e4bdcd 61/81: Change: Sync with accept-process-output, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 65030d5cc1 64/81: Tidy: Docstring, ELPA Syncer, 2022/05/11
- [elpa] externals/plz dd92f48895 65/81: Change: Default to :then 'sync and :as 'string, ELPA Syncer, 2022/05/11
- [elpa] externals/plz cddccccf81 67/81: Docs: Fix link, ELPA Syncer, 2022/05/11
- [elpa] externals/plz f1a89a8816 68/81: Add: Download :as file, ELPA Syncer, 2022/05/11
- [elpa] externals/plz 8cd1ef481d 73/81: Notes: Add links to skeeto's feedback, ELPA Syncer, 2022/05/11
- [elpa] externals/plz dd491941ab 79/81: Meta: Update makem.sh, ELPA Syncer, 2022/05/11