Jump to content

Odd GET requests


darkassassin07
 Share

Go to solution Solved by pir8radio,

Recommended Posts

darkassassin07

With the most recent update, the app no longer allows you to put a path in the host field while adding a server (example: https://mydomain.com/mymedia/).

App version 3.0.2

 

The first request the android app makes to the host its been given is "GET /emby HTTP/1.1".

While I happened to be using the location "/emby" to direct traffic through my reverse proxy, if I wanted to change that to something like "/mymedia" this is no longer possible.

 

 

@@Luke The use of /emby threw you I think, so I'll try to be more clear using /mymedia as my proxy location:

(this was my setup before the recent change just with /mymedia edited in instead of /emby)

 

 

The app host field is (well was) set to "https://mydomain.com/mymedia"with the correct port.

The emby external address shown in the dashboard is "https://mydomain.com/mymedia:443"

When the app tries to connect it sends the request "GET /mymedia/emby HTTP/1.1" to mydomain.com.

This request is received by the reverse proxy where it is matched to the location /mymedia.

The proxy strips /mymedia from the URI passing the request "GET /emby HTTP/1.1" to the emby server.

 

 

 

Because of this change this kind of setup is no longer possible. Your emby server can only ever reside at the root of your reverse proxy (ie: '/') or the location '/emby'.

The app now sends the request "GET /emby HTTP/1.1" which in this example gets a 404 from the proxy without being passed to the emby server.

Then it tries "GET /emby/system/info/public HTTP/1.1" which also receives a 404.

This can no-longer be changed.

 

 

 

 

The only issues I was having with the previous setup was having the request "GET /mymedia/:443/emby/system/info/public HTTP/1.1" sent to my proxy every few minutes filling my logs with garbage, and the websocket request being sent to "/embywebsocket" instead of "/mymedia/embywebsocket" like every other request the app made.

Edited by darkassassin07
Link to comment
Share on other sites

We've never officially supported custom subpaths. The apps are always going to auto-add /emby.

Link to comment
Share on other sites

darkassassin07

I guess this has turned into a feature request then. Now that support has been added to have emby behind a proxy, this would make sense would it not?

 

Emby is one of a few things I host, eventually I plan to have an index/landing page at the root of mydomain.com where a user can then link to any one of the services. The apps however will still need to be able to directly connect to emby through the /mymedia path. I just happened to be using /emby for that path.

Link to comment
Share on other sites

Well we've managed to get this far without it. The problem is then we have to put a field for that on our connection screens, and users already think the connection process is complicated enough.

Link to comment
Share on other sites

darkassassin07

... No you wouldn't...? Just allow the user to put the full host path just as I was.

Ie

host: 'https://mydomain.com/mymedia'

Port: '1234'

 

 

You haven't needed it for most people so far, but you only recently added the option to have emby behind a proxy.

Edited by darkassassin07
Link to comment
Share on other sites

... No you wouldn't...? Just allow the user to put the full host path just as I was.

Ie

host: 'https://mydomain.com/mymedia'

Port: '1234'

 

 

You haven't needed it for most people so far, but you only recently added the option to have emby behind a proxy.

 

Well, I think the officially supported reverse proxy configuration is using sub-domains not sub-directories.    All apps support the sub-domain method of a reverse proxy.   I would say sub directories are unsupported considering like 95% of the reverse proxy connection issues on this forum are related to sub directories and the proxy not being transparent to the application server. 

 

Just my two cents though..   :)

Link to comment
Share on other sites

darkassassin07

I would say sub directories are unsupported considering like 95% of the reverse proxy connection issues on this forum are related to sub directories and the proxy not being transparent to the application server.

Do you mean 'issues related to sub directories' as in people are trying to do something similar and its not working?

Ofc it isn't, the app doesn't currently prepend the uri the user had given it to the requests its making.

It really shouldn't be hard to take the uri entered into the host field and add it to any request the apps make to that particular server.

Turning 'GET /embywebsocket?<args>' into 'GET /mymedia/embywebsocket?<args>'

 

This would allow myself and other users to put the server in a subdirectory of a domain without adding any extra fields or complication to the average user.

I don't see a downside?

 

One of the problems with using a sub domain for me is that ddwrt provides local domain names for devices with a static dhcp lease. This only allows me to configure a single name per device and setting this to the same domain name allows me and my family to connect with the same domain name no matter where we are. If emby was the only thing I host that wouldn't be a problem, but I have several services that are all under that same name. Then as I have mentioned, the hassle of dealing with multiple domain names when it comes to re-creating my certs with manual dns verification every 3mo (LE)...

 

I would also have to stick to several (sub) domains for every service because telling my users 'ok this one you add emby to the beginning like emby.mydomain.com and these three you have to put it after like mydomain.com/serviceA'. I get bothered enough by those that forget the 'https://' (port 80 is blocked by isp)

Link to comment
Share on other sites

Do you mean 'issues related to sub directories' as in people are trying to do something similar and its not working?

Ofc it isn't, the app doesn't currently prepend the uri the user had given it to the requests its making.

It really shouldn't be hard to take the uri entered into the host field and add it to any request the apps make to that particular server.

Turning 'GET /embywebsocket?<args>' into 'GET /mymedia/embywebsocket?<args>'

 

This would allow myself and other users to put the server in a subdirectory of a domain without adding any extra fields or complication to the average user.

I don't see a downside?

 

One of the problems with using a sub domain for me is that ddwrt provides local domain names for devices with a static dhcp lease. This only allows me to configure a single name per device and setting this to the same domain name allows me and my family to connect with the same domain name no matter where we are. If emby was the only thing I host that wouldn't be a problem, but I have several services that are all under that same name. Then as I have mentioned, the hassle of dealing with multiple domain names when it comes to re-creating my certs with manual dns verification every 3mo (LE)...

 

I would also have to stick to several (sub) domains for every service because telling my users 'ok this one you add emby to the beginning like emby.mydomain.com and these three you have to put it after like mydomain.com/serviceA'. I get bothered enough by those that forget the 'https://' (port 80 is blocked by isp)

 

 

I run about 10 subdomains myself.   I would make all of your services subdomains and just get a wildcard cert.   The ddwrt names wouldn't be affected by using different subdomains on the wan side.    Nginx handles the direction of subdomains through headers. 

Link to comment
Share on other sites

darkassassin07

-edit- ill look into that in a bit, last I had read I couldn't use a wildcard in dns verification

Edited by darkassassin07
Link to comment
Share on other sites

-edit- ill look into that in a bit, last I had read I couldn't use a wildcard in dns verification

I guess im not sure what you mean by "dns verification"?

Link to comment
Share on other sites

darkassassin07

Proving you own/control said domain name via dns txt records while getting a cert.

 

Im probably mixing up my terminology a bit...

Edited by darkassassin07
Link to comment
Share on other sites

  • Solution

Proving you own/control said domain name via dns txt records while getting a cert.

 

Im probably mixing up my terminology a bit...

 

gotcha...  yea, you can still verify with a wildcard.   you just do it on your base domain name..    domain.com  

  • Like 1
Link to comment
Share on other sites

I ended up getting the wildcard cert then setting up subdomains on lan and wan. Thanks @@pir8radio

 

i'm just glad its working for you...   sub domains really takes the headaches out of a reverse proxy..  

Link to comment
Share on other sites

  • 3 weeks later...
darkassassin07

While it isn't really a major issue,

With the current beta branch of emby for android the app is still making the request:

[14/Aug/2018:22:48:17 -0600] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 564

 

(this is from my nginx access log)

The odd part is the host name listed in the dashboard of the server as well as what was manually entered into the app is emby.mydomain.com. Everything sent to emby.mydomain.com is proxied/proxyed? to the emby server while mydomain.com is a dead end currently.

 

This request is resent correctly as emby.mydomain.com/emby/system/info/public shortly after so it isn't actually breaking anything, it's just odd.

Edited by darkassassin07
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...