I'm setting up Apache on Centos the way I have done in the past, but for some reason mod_spdy is not running. I'm following the instructions here:
https://developers.google.com/speed/spdy/mod_spdy/
When I run rpm -U mod-spdy-beta_current_x86_64.rpm I get this message:
warning: mod-spdy-beta_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
package mod-spdy-beta-0.9.4.3-420.x86_64 is already installed
If I open chrome://net-internals/#spdy and my site in another tab, it doesn't show my site. If I look in the network panel, I don't see the x-mod-spdy header.
Update: If I use Firefox firebug, I see the x-mod-spdy header. I don't see my site in Chrome spdy sessions, but I see other sites in it.
What could I be doing wrong?
Ok it seems the issue is that Chrome 40.x dropped support for SPDY/3 and only supports SPDY/3.1, but the mod_spdy module for Apache only supports SPDY/3, so basically no SPDY for Chrome users if you use Apache as a web server.
mod_spdy is currently in a bad state where either Google nor Apache is maintaining it after Google donated it to the Asf. Google recently made the statement that they will drop the SPDY support from Chrome in early 2016, but what they forgot to say that they started dropping older versions of SPDY already (including SPDY/3) (I like these partially true statements by the way), so basically if you are on Apache then for your Chrome users you can't provide SPDY short of implementing SPDY/3.1 yourself.
So, how was that "do no evil"? :-)
See details: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y
and https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars
One option you might consider is switching to Nginx and using SPDY/3.1 over there.
Related
The latest update of PSI is reporting that all our site pages are using HTTP1/1 when in the fact they are running under HTTP/2. Confirmed this with the domain host and two separate tests.
Yup can confirm you're definitely using HTTP/2.
This looks to be a bug with PageSpeed Insights and looks like you're not the only one experiencing it.
If you run Lighthouse locally (either through Chrome, or even with the command line), or through Web Page Test then it doesn't complain about missing HTTP/2 but it does for PageSpeed Insights and web.dev/measure.
Suggest you follow that GitHub issue I linked above, and maybe add a comment with your own site.
I can’t run local testing(for example http://localhost:3000) on browserstack.
I'm using Linux Mint 18.3 Sylvia x64. Browser is Chromium.
The browser’s extension (app) is installed.
The screenshot shows that there is no connection.
http://joxi.ru/Y2LJBv0H9MBv8r
The checkbox is checked.
http://joxi.ru/1A5PvVpCnzMww2
I tried this manual https://www.browserstack.com/local-testing.
./BrowserStackLocal --key
The above command is started, but nothing happened.
BrowserStack's Support Answer:
Thank you for joining the screen share session. As per our investigation, it seems that few of the IP's of our servers hosted on AWS are blocked due to Telegram blockage by Roskomnadzor which is leading towards the issue.
Having said that, our team is evaluating alternate solutions for our Russian users and I will be sure to notify you of the developments.
Cool!
But my neighbour doesn't have problems, he has Windows.
We have a common Internet provider.
Try replacing 'localhost' in the URL you are using with the IP address of the machine. For example, if you are testing the URL "http://localhost:3000/index.html" try using http://<machine_ip_address>:3000/index.html instead.
The Issue:
I've recently been working enabling HTTP/2 for a large PHP+JS application (generally a Backbone-based SPA served by a PHP back-end). While most resources load fine, two requests are getting stuck in the "Stalled" state for exactly 5 minutes before resolving and downloading as normal.
The two request in question are a simple XMLHttpRequest to our back-end and a request for a Font Awesome font file. Other font files and back-end requests are loaded just fine, but these two will consistently hang up when HTTP/2 is enabled.
Debugging Information:
Here are the headers associated with the font file request listed in Chrome's dev tools:
...and here's the output from chrome://net-internals, with the hangup occurring at HTTP_TRANSACTION_READ_HEADERS (see the dt of almost 30000ms):
Further Details:
This application is served using a build of apache2 that includes the mod_http2 module rather than the standard version of apache2 that is packaged with Ubuntu. The same behavior is reported in the latest versions of Firefox, Chrome, and Chrome beta on Ubuntu 16.04.
For the sake of local development, all SSL is being run through a self-signed OpenSSL certificate, generated with OpenSSL version 1.0.2j.
It should also be noted that all other successful requests are running through Backbone-related methods, which delegate to jQuery's $.ajax, where the failed XMLHttpRequest is using the native JS XMLHttpRequest Object.
Thanks for your help.
What version of Apache and mod_http2 are you using?
There's been a load of fixes for this sort of thing and Apache 2.4.25 is about to be released including those fixes, so suggest you upgrade to that when it comes out in next day or two and try again.
Alternatively, if you don't want to wait, you can try updating mod_http2 independently by doing the following (assuming Apache is installed in /usr/local/apache2/ but adjust that as appropriate):
#Download and install mod_http2 outside of a regular Apache release
#Latest version is here: https://github.com/icing/mod_h2/releases/
wget https://github.com/icing/mod_h2/releases/download/v1.8.3/mod_http2-1.8.3.tar.gz
tar -zxvf mod_http2-1.8.3.tar.gz
cd mod_http2-1.8.3
./configure --with-apxs=/usr/local/apache2/bin/apxs
make
sudo make install
Then restart Apache and confirm from error log that you are running mod_http2-1.8.3.
If that doesn't work then raise an issue here: https://github.com/icing/mod_h2/ as the mod_http2 developer (#icing) is very responsive to issues. Assuming this is an Apache bug of course.
I have just successfully deployed Quercus on Glassfish 4.1. I tested in the browser
http://localhost:8080/quercus-4.0.39/ and saw this:
Congratulations! Quercus™ Open Source 4.0.39 is interpreting PHP
pages. Have fun!
Then ran Netbeans Tools > Options > PHP > Activate PHP Support
It worked. I now see this:
So I made 3 tests:
I ran a php page in an html application but instead of displaying the page it prompts a download box to open in Notepad
I created a new PHP project with below configuration:
But when I run the app with above configuration I receive this error:
Firefox can't establish a connection to the server at localhost.
So I tried with a third test with other configuration:
When I run this third test I get a HTTP Status 404 - Not Found error on GlassFish server.
What am I doing wrong? Thank you!
The problems with your tests are:
PHP needs to be interpreted by a web server. Your browser doesn't know what to do with a PHP file, so it just treats it like a file rather than a page to render. Apache is the most common and easiest server to do that with, GlassFish is unnecessary and probably not the best choice for PHP.
In this test, you are trying to visit a web server which doesn't exist. You don't have any server that listens on port 80.
Here, GlassFish is reporting that it can't find the resource you requested. Have you made sure to put your PHP project in the right directory for Quercus (like in step 4 of your documentation link) and made sure you're visiting a valid URL?
I think the best thing for you to do is move away from Quercus. The latest version of it is very old and implements an old version of PHP (version 5, whereas the latest is 5.6). Looking at the official website, the project appears to be dead, with broken links and very old documentation.
I would suggest you investigate installing a WAMP (Windows, Apache, MySQL, PHP) or LAMP (Linux, Apache, MySQL, PHP) stack. There are lots of very easy installers for this approach which will help you get up to speed and a lot of helpful tutorials and documentation.
For those who using tomcat, below are the steps :-
Right click your project --> properties --> Run Configuration --> For Run As, select PHP Built-in Web Server
Go to Tools --> Options --> PHP tab --> in Php 5 interpreter, browse the correct location for php
Then it should works !
In my case , my php is in /usr/bin/php7.0, so I put the path in Php 5 interpreter.
Experimenting with Phantomjs to scrape some information from a vendor application our company uses. When I open the page and render it, I can see that the only output is the message
SPNEGO authentication is not supported on this client.
I had seen that message in Firefox before, and the solution was to add the host to the trusted uris. That's great for FF, but in the context of a phantomjs script, is there a way to declare a site as trusted?
UPDATE: Tried the command-line parameters per Artjom's suggestion but no difference.
I don't think this protocol is implemented in PhantomJS. PhantomJS is built on top of QtWebKit. I found an old Aurora issue. Aurora is also based on QtWebKit.
If you search for SPNEGO or kerberos in the phantomjs repo, you don't find much. Searching for negotiate shows only some constants, but no actual implementation.