Fork me on GitHub
#yada
<
2018-03-14
>
matttylr11:03:35

Hi @malcolmsparks, just the man 🙂

matttylr11:03:06

getting a

Not found

https://:8443
from my yada deployment

matttylr11:03:36

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

malcolmsparks11:03:36

Vhosts not matching

malcolmsparks11:03:14

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

malcolmsparks11:03:26

Doesn't use HOST

malcolmsparks11:03:37

Sorry, taking off

matttylr11:03:47

cool, enjoy the trip 🙂

matttylr11:03:27

are you literally sitting in the plane now?

malcolmsparks11:03:55

Aircraft sped up, then suddenly braked. LHR

matttylr11:03:18

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

malcolmsparks11:03:19

Pilot must badly want me to help fix your issue

malcolmsparks11:03:14

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

malcolmsparks11:03:50

Best to use actual names if you can.

matttylr11:03:55

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

matttylr11:03:44

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?

malcolmsparks11:03:07

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

malcolmsparks11:03:50

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

malcolmsparks11:03:25

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

matttylr11:03:34

yes, and a parallel deployment for another host does work

matttylr11:03:41

ok, I’ll take a look there

malcolmsparks11:03:02

Is there another header in use on your setup?

malcolmsparks11:03:44

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

malcolmsparks11:03:10

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

matttylr11:03:30

ok, those are great pointers, cheers @malcolmsparks

malcolmsparks11:03:42

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

malcolmsparks11:03:48

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

malcolmsparks11:03:10

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

malcolmsparks11:03:26

If so, you could patch bidi accordingly

malcolmsparks11:03:58

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

malcolmsparks11:03:43

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

matttylr11:03:19

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

matttylr11:03:58

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

matttylr11:03:06

(with the working and non-working hosts)

malcolmsparks11:03:06

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

matttylr11:03:26

rattling sound might come from the passengers though….

malcolmsparks11:03:56

Could you paste curl -v

malcolmsparks11:03:28

(curse you SwiftKey!)

matttylr11:03:36

not easily, you know, bank

matttylr11:03:45

but Host: is def being sent

matttylr11:03:51

and it’s correct

malcolmsparks11:03:56

Right. That's what I was looking for.

matttylr11:03:40

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

malcolmsparks11:03:55

Look at the bidi vhosts ns

matttylr11:03:00

I’m there

matttylr11:03:55

it looks for x-forwarded-host or host

matttylr11:03:11

can’t see how that’s not working

malcolmsparks11:03:31

Look at vhosts->routes

malcolmsparks11:03:13

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

malcolmsparks11:03:05

Have you used an actual string in your vhost?

malcolmsparks11:03:13

Or a wildcard?

matttylr11:03:14

contrasting with the working one

malcolmsparks11:03:21

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.

malcolmsparks11:03:42

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

matttylr11:03:44

both have the form

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

matttylr11:03:27

there’s no silly extraneous spaces either

matttylr11:03:13

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

matttylr11:03:38

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

malcolmsparks11:03:20

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