unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Tristan Colgate <tcolgate@gmail.com>
To: Derek Upham <derek_upham@mailfence.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: [Patch] Support HTTP/2 in HTTP client
Date: Wed, 1 Apr 2020 08:24:12 +0100	[thread overview]
Message-ID: <CAPGZSGLfMgsVrGxy7pSaXGzAKXtG4fATTSjbk7xPeC1QZsh-Sw@mail.gmail.com> (raw)
In-Reply-To: <87sghongp7.fsf@priss.frightenedpiglet.com>

I'm not sure why a server would give you a http2 response if you
didn't ask for one (or atleast suggest you could accept one), in the
tls ALPN. If it happened on a non-tls request, I'm even more confused.
  Note that curl, without extra cli options, will negotiate http2, so
you need to make sure that guile actually saw that, and not just
assume that it did because curl saw it (you can force the http version
with, e.g. --http1.1)
  If you get a http/2 response, the client, as is, wont be able to
process it anyway, so error'ing is very must the right thing to do.
http/2 isn't just a cosmetic change, it's an entirely different
protocol, not text based, multi request/response streams, an
compression mechanism that uses pre-baked tables based on online
observed data.

On Wed, 1 Apr 2020 at 02:22, Derek Upham <derek_upham@mailfence.com> wrote:
>
> I made this particular tweak because Guile 2.2’s HTTP/1.1 client
> requests were getting back an HTTP/2 response from a podcast
> server, and choking.  (The use of Google’s URL was just an example
> to show the format of the HTTP response header.)   Let’s drop the
> patch for now.  I’ll try disabling it locally and see whether I
> can still reproduce it.  Given the amount of redirects that media
> website backends do, it’s possible that I’ll never come across the
> problem again.
>
> Derek
>
> Tristan Colgate <tcolgate@gmail.com> writes:
>
> > http/2 is a substantially different protocol, it will take
> > considerable effort to support it, guile's client should only be
> > offering http/1.1 to the server.
> >
> > On Tue, 31 Mar 2020 at 15:49, Derek Upham
> > <derek_upham@mailfence.com> wrote:
> >>
> >> Companies like Google now respond to HTTP requests with HTTP 2.
> >> For example:
> >>
> >>   curl --silent --head https://www.google.com
> >>
> >> returns the first line
> >>
> >>   HTTP/2 200
> >>
> >> The Guile HTTP client code expects a “HTTP/x.y” structure, and
> >> treats this as an error.  This patch recognizes and handles
> >> “HTTP/2” on input and output.  HTTP version numbers don’t
> >> proliferate quickly, so the code uses a brute force approach
> >> for
> >> now.
> >>
> >>
> >> Derek
> >>
> >> --
> >> Derek Upham
> >> derek_upham@mailfence.com
>
>
> --
> Derek Upham
> derek_upham@mailfence.com
>


-- 
Tristan Colgate-McFarlane
----
  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"I'm not sure why a server would give you a http2
response if you didn't ask for one (or atleast suggest you could
accept one), in the tls ALPN. If it happened on a non-tls request, I'm
even more confused.
  If you get a http/2 response, the client, as is, wont be able to
process it anyway, so error'ing is very must the right thing to do.
http/2 isn't just a cosmetic change, it's an entirely different
protocol, not text based, multi request/response streams, a

On Wed, 1 Apr 2020 at 02:22, Derek Upham <derek_upham@mailfence.com> wrote:
>
> I made this particular tweak because Guile 2.2’s HTTP/1.1 client
> requests were getting back an HTTP/2 response from a podcast
> server, and choking.  (The use of Google’s URL was just an example
> to show the format of the HTTP response header.)   Let’s drop the
> patch for now.  I’ll try disabling it locally and see whether I
> can still reproduce it.  Given the amount of redirects that media
> website backends do, it’s possible that I’ll never come across the
> problem again.
>
> Derek
>
> Tristan Colgate <tcolgate@gmail.com> writes:
>
> > http/2 is a substantially different protocol, it will take
> > considerable effort to support it, guile's client should only be
> > offering http/1.1 to the server.
> >
> > On Tue, 31 Mar 2020 at 15:49, Derek Upham
> > <derek_upham@mailfence.com> wrote:
> >>
> >> Companies like Google now respond to HTTP requests with HTTP 2.
> >> For example:
> >>
> >>   curl --silent --head https://www.google.com
> >>
> >> returns the first line
> >>
> >>   HTTP/2 200
> >>
> >> The Guile HTTP client code expects a “HTTP/x.y” structure, and
> >> treats this as an error.  This patch recognizes and handles
> >> “HTTP/2” on input and output.  HTTP version numbers don’t
> >> proliferate quickly, so the code uses a brute force approach
> >> for
> >> now.
> >>
> >>
> >> Derek
> >>
> >> --
> >> Derek Upham
> >> derek_upham@mailfence.com
>
>
> --
> Derek Upham
> derek_upham@mailfence.com
>


-- 
Tristan Colgate-McFarlane
----
  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"



  reply	other threads:[~2020-04-01  7:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 14:42 [Patch] Support HTTP/2 in HTTP client Derek Upham
2020-03-31 15:00 ` Tristan Colgate
2020-04-01  1:21   ` Derek Upham
2020-04-01  7:24     ` Tristan Colgate [this message]
2020-04-07 14:39     ` Derek Upham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPGZSGLfMgsVrGxy7pSaXGzAKXtG4fATTSjbk7xPeC1QZsh-Sw@mail.gmail.com \
    --to=tcolgate@gmail.com \
    --cc=derek_upham@mailfence.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).