Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blank page on connection #3

Closed
Erwyn opened this issue Aug 29, 2019 · 5 comments
Closed

Blank page on connection #3

Erwyn opened this issue Aug 29, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@Erwyn
Copy link

Erwyn commented Aug 29, 2019

Hello!

I'm trying to run Hauk with your docker image but I always end up on a blank page and when I try to start sharing my location with my phone I get an an error. Here are my logs:

docker logs -f hauk
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.20. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.20. Set the 'ServerName' directive globally to suppress this message
[Thu Aug 29 16:37:41.131733 2019] [mpm_prefork:notice] [pid 14] AH00163: Apache/2.4.38 (Debian) PHP/7.3.8 configured -- resuming normal operations
[Thu Aug 29 16:37:41.131782 2019] [core:notice] [pid 14] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND'
172.18.0.19 - - [29/Aug/2019:16:37:47 +0000] "GET / HTTP/1.1" 200 1378 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.18.0.19 - - [29/Aug/2019:16:37:47 +0000] "GET /style.css HTTP/1.1" 200 1446 "https://my.super.address/" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.18.0.19 - - [29/Aug/2019:16:37:47 +0000] "GET /main.js HTTP/1.1" 200 3064 "https://my.super.address/" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.18.0.19 - - [29/Aug/2019:16:37:47 +0000] "GET /dynamic.js.php HTTP/1.1" 200 679 "https://my.super.address/" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.18.0.19 - - [29/Aug/2019:16:37:47 +0000] "GET /assets/logo.svg HTTP/1.1" 304 126 "https://my.super.address/" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"

I used your config.php just changed password (and it seems to work as if I put the wrong password in the mobile app I get a proper error) and the public url to match mine.

Here is a mobile screenshot:

Screenshot_20190829_184040_info varden hauk

@bilde2910
Copy link
Owner

That's strange. Apparently the server is correctly sending the handshake reply to the app, but the app is interpreting it as an error. It's a pretty easy client-side fix, but I'm still curious about what exactly is being returned here.

First, I'd like to rule out the app as the faulty part. Is it possible for you to try the app against the demo server? If that succeeds, something is wrong with the server stack (either the image itself, or some proxy in front of it). If it fails, the app is broken.

Next, if the demo server does work - is there any chance you could run this command against your own server in your terminal and paste the output here? It will give me a hexdump of the entire HTTP handshake reply, but with your hostname removed.

Just replace YOUR_PASSWORD and YOUR_SIDE_ADDRESS accordingly.

curl -X POST https://YOUR_SITE_ADDRESS/api/create.php -F pwd=YOUR_PASSWORD -F dur=10 -F int=1 -D - 2>/dev/null | sed -e 's/YOUR_SITE_ADDRESS/redacted-hostname/g' | hexdump -C

If you want to see what data you're sending me first, just remove | hexdump -C from the end. The hexdump is so I can see if there are any stray bytes in the response that could arise from something funky going on with Apache.

Finally, the blank page - could you check if there are any errors in the Network or Console tabs of developer tools (F12)? Might have to reload the page with those open for something to show up.

@Erwyn
Copy link
Author

Erwyn commented Aug 30, 2019

That's strange. Apparently the server is correctly sending the handshake reply to the app, but the app is interpreting it as an error. It's a pretty easy client-side fix, but I'm still curious about what exactly is being returned here.

First, I'd like to rule out the app as the faulty part. Is it possible for you to try the app against the demo server? If that succeeds, something is wrong with the server stack (either the image itself, or some proxy in front of it). If it fails, the app is
broken.

The mobile app is working against the demo server so we can rule that out.

Next, if the demo server does work - is there any chance you could run this command against your own server in your terminal and paste the output here? It will give me a hexdump of the entire HTTP handshake reply, but with your hostname removed.

Just replace YOUR_PASSWORD and YOUR_SIDE_ADDRESS accordingly.

curl -X POST https://YOUR_SITE_ADDRESS/api/create.php -F pwd=YOUR_PASSWORD -F dur=10 -F int=1 -D - 2>/dev/null | sed -e 's/YOUR_SITE_ADDRESS/redacted-hostname/g' | hexdump -C

00000000  48 54 54 50 2f 32 20 32  30 30 20 0d 0a 63 6f 6e  |HTTP/2 200 ..con|
00000010  74 65 6e 74 2d 74 79 70  65 3a 20 74 65 78 74 2f  |tent-type: text/|
00000020  68 74 6d 6c 3b 20 63 68  61 72 73 65 74 3d 55 54  |html; charset=UT|
00000030  46 2d 38 0d 0a 64 61 74  65 3a 20 46 72 69 2c 20  |F-8..date: Fri, |
00000040  33 30 20 41 75 67 20 32  30 31 39 20 30 37 3a 35  |30 Aug 2019 07:5|
00000050  32 3a 34 33 20 47 4d 54  0d 0a 73 65 72 76 65 72  |2:43 GMT..server|
00000060  3a 20 43 61 64 64 79 0d  0a 73 65 72 76 65 72 3a  |: Caddy..server:|
00000070  20 41 70 61 63 68 65 2f  32 2e 34 2e 33 38 20 28  | Apache/2.4.38 (|
00000080  44 65 62 69 61 6e 29 0d  0a 76 61 72 79 3a 20 41  |Debian)..vary: A|
00000090  63 63 65 70 74 2d 45 6e  63 6f 64 69 6e 67 0d 0a  |ccept-Encoding..|
000000a0  78 2d 70 6f 77 65 72 65  64 2d 62 79 3a 20 50 48  |x-powered-by: PH|
000000b0  50 2f 37 2e 33 2e 38 0d  0a 63 6f 6e 74 65 6e 74  |P/7.3.8..content|
000000c0  2d 6c 65 6e 67 74 68 3a  20 31 30 37 0d 0a 0d 0a  |-length: 107....|
000000d0  0a 4f 4b 0a 65 36 66 61  61 33 32 38 64 36 33 36  |.OK.e6faa328d636|
000000e0  33 65 31 35 35 64 65 33  65 65 39 30 64 30 36 64  |3e155de3ee90d06d|
000000f0  65 63 66 33 64 30 62 63  30 31 66 33 37 37 64 38  |ecf3d0bc01f377d8|
00000100  37 66 61 33 34 32 39 32  30 33 38 34 62 37 39 31  |7fa342920384b791|
00000110  33 35 39 62 0a 68 74 74  70 73 3a 2f 2f 72 65 64  |359b.https://red|
00000120  61 63 74 65 64 2d 68 6f  73 74 6e 61 6d 65 2f 3f  |acted-hostname/?|
00000130  36 36 50 37 2d 53 57 43  53 0a                    |66P7-SWCS.|
0000013a

If you want to see what data you're sending me first, just remove | hexdump -C from the end. The hexdump is so I can see if there are any stray bytes in the response that could arise from something funky going on with Apache.

Finally, the blank page - could you check if there are any errors in the Network or Console tabs of developer tools (F12)? Might have to reload the page with those open for something to show up.

Okay, something interesting here, here is what I get in my dynamic.js.php:

<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /etc/hauk/config.php:78) in <b>/var/www/html/dynamic.js.php</b> on line <b>7</b><br />
var TILE_URI = "https:\/\/{s}.tile.openstreetmap.org\/{z}\/{x}\/{y}.png";
var ATTRIBUTION = "";
var DEFAULT_ZOOM = 14;
var MAX_ZOOM = 19;
var MAX_POINTS = 100;
var VELOCITY_DELTA_TIME = 2;
var TRAIL_COLOR = "#d80037";
var VELOCITY_UNIT = {"havMod":45871200,"mpsMod":3.6,"unit":"km\/h"};

@bilde2910
Copy link
Owner

Thanks a lot for the helpful hexdump and error message! Looks like there is indeed a stray newline in the output:

0x000000cc: 0d 0a 0d 0a 0a 4f 4b
                        ^^

And this also connects to the warning you see in dynamic.js.php - there's a newline apparently coming from after the ?> tag at the end of config.php; Hauk tries to send some headers after the config file has started outputting this newline.

Might be possible to solve this if the PHP tag isn't closed by that tag. Can you try just removing the ?> at the end of the config.php file and see if that fixes the issue?

@bilde2910 bilde2910 added the bug Something isn't working label Aug 30, 2019
@Erwyn
Copy link
Author

Erwyn commented Aug 30, 2019

It fixes it. And yes there was a trailing line.

Thank you very much !

Out of curiosity, how did you get that:

0x000000cc: 0d 0a 0d 0a 0a 4f 4b
                        ^^

@Erwyn Erwyn closed this as completed Aug 30, 2019
@bilde2910
Copy link
Owner

Awesome! I'll patch the default config so other don't get this issue.

Out of curiosity, how did you get that:

That was a snip from your hexdump:

image

HTTP headers are delimited by the body with "\r\n\r\n" or 0x0d 0x0a 0x0d 0x0a. The start of line 0x000000d0 shows an extra 0x0a; the newline that wasn't supposed to be there, which was then included as part of the body.

bilde2910 added a commit that referenced this issue Aug 30, 2019
Extra newlines at the end of the file would cause Hauk to malfunction. This fixes the issue.
TheCataliasTNT2k pushed a commit to TheCataliasTNT2k/hauk that referenced this issue Apr 1, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants