Getting a Bad Request response when including Host header on staging API

Hi,

I’m developing a client and I’ve come across a strange problem that I can’t seem to overcome.

I’ve got an HTTPS request library that works perfectly fine for every application I’ve ever used it for, but if I submit a request to the staging API and the request includes the host header (which is always the correct host) I get a 400 bad request response. If I omit the host header, the request succeeds.

I’ve spent a whole day on this.

Any ideas on how to figure this out?

Edit: Also, the error is from nginx.

Not without a lot more information, now it's just a guessing game. Can you provide verbose logging of both failing and succeeding attempts?

4 Likes

I guess this could be a question about Nginx or http requests in general, but at the moment, it’s only failing with the Let’s encrypt staging api.

I thought there might have been some extra weirdness in RFC 8555 that forbids lower case host headers or the host header has to come first, but not on Tuesdays or something.

No specific weirdness in RFC 8885, it just says that connections use HTTPS. (Well, it specifically refers to RFC 2818, but I'm assuming that later versions of HTTPS are expected to be allowed as well.)

One thing to be aware of is that Let's Encrypt's endpoints seem to work over HTTP/2 (in addition to older versions), and I know that HTTP/2 has a bit more complicated method of specifying hosts & "authority" and whatnot than HTTP/1.1 does (though I haven't yet had the pleasure of needing to dig into details on them myself). So you might want to double-check which HTTP version your client is using, and that it's doing what it's supposed to.

But without some sample code, or some more verbose logging, or whatnot, I don't think people here will really be able to help you. (And when you say only LE staging doesn't work, do you mean that your code works when pointed to production, but not staging? Since that would really surprise me.)

7 Likes

That’s actually some good info.

When I restrict the client to http1 only it works as expected. I’ll have to dig in to the http2 host/authority stuff myself.

I say the staging API because it’s the first place I’ve had the problem. I’m pretty sure the client would have made http2 connections in the past and not had errors.

I’ve got trace level logs, but they’re identical between success and failure apart from the frame size of the header frames.

Thanks

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.