Clojurians Log v2

Morning

Hi

Hi @malcolmsparks, just the man 🙂

getting a

Not found

https://:8443

but my vhost config seems correct, it’s like yada isn’t able to pick up the HOST or HOSTNAME env var

Vhosts not matching

yada looks at the request and x-forwarded-proto header

Doesn't use HOST

Sorry, taking off

ah, yes

cool, enjoy the trip 🙂

Was, aborted!

Yikes

are you literally sitting in the plane now?

Yep

nice

Aircraft sped up, then suddenly braked. LHR

you wouldn’t get that level of product support from commercial software

Pilot must badly want me to help fix your issue

🙂

yada doesn't use env vars but you can in your setup code.

Best to use actual names if you can.

yes, sorry, that isn’t what I meant, using the wrong words for what was in my head

it’s just strange that the domain/host string is absent in the error msg, that would indicate that it wasn’t reading it from the header?

Technical issue on the flight deck. Doesn't seem to be yada related though

Ah. Yes, that's strange. Are you behind a proxy?

Look at the bidi vhosts ns to see how vhosts are matched

yes, and a parallel deployment for another host does work

ok, I’ll take a look there

Is there another header in use on your setup?

Technically this is a bidi issue but be aware yada adds a protocol extension to bidi in yada/ext/bidi.

Be aware of that when you're piecing together this puzzle

ok, those are great pointers, cheers @malcolmsparks

Can't quite remember the request header that is also used. Think it is x-forward-proto but obviously I'm afk right now.

Aircraft is banjaxed (it's operated by SAS Ireland so I think that's the correct term here.)

heck

Your proxy might be sending a different nonstandard header. You could dump the request which might help to see what it is doing. It might be an older proxy before this stuff was standardised

If so, you could patch bidi accordingly

Just add the header wherever x-forwarded-host is used

Not banjaxed. Engineers need to look at a few 'bits and pieces'. Not a reassuring term in the context of an aeroplane

there’s quite a few bits and pieces on a plane, might take a while

going direct via curl, sans proxy, give the same responses

(with the working and non-working hosts)

They could give it a shake and listen for a rattling sound

rattling sound might come from the passengers though….

Could you paste curl -v

(curse you SwiftKey!)

not easily, you know, bank

Ah sure

but Host: is def being sent

and it’s correct

Right. That's what I was looking for.

I don’t think this is yada/bidi, but just wanted to know where they were looking

Look at the bidi vhosts ns

I’m there

it looks for x-forwarded-host or host

Yes

can’t see how that’s not working

Look at vhosts->routes

It's pulling from your vhost declaration. Not your request

Have you used an actual string in your vhost?

Or a wildcard?

string

contrasting with the working one

The vhosts->string fn is the problem here. It is looking for host in the map. You can see how the error is constructed. There must be something you're doing to the map.

It's odd that it's working on the other node

both have the form

[{:scheme :https, :host "hostname:8443"}]

there’s no silly extraneous spaces either

hmm, as I say, believe it’s something environmental

I’ve got to pop out for a bit, thanks for the pointers Malcolm, I hope you take off soon

So it looks like host is changing from hostname:8443 to :8443. The request itself isn't involved

Ok