Giter Site home page Giter Site logo

davidalger / devenv Goto Github PK

View Code? Open in Web Editor NEW
20.0 7.0 13.0 812 KB

Vagrant Development Environment for Mac OS X Hosts

License: Open Software License 3.0

Shell 25.33% Ruby 17.40% PHP 23.75% VCL 0.84% Groovy 0.01% Python 1.04% Vim Script 31.63%
magento2 magento2-vagrant magento2-devbox

devenv's Introduction

Development Environment

This setup relies on Vagrant and VirtualBox (or VMWare Fusion if that's what you prefer) running on Mac OS X to power the virtualized developer environment. These dependencies are installed as part of the setup process using Homebrew and Homebrew Cask.

It is setup with different machines running different versions of PHP. The machines provide all the necessary components to build on Magento, including support for running multiple PHP versions side-by-side if necessary (see below for details). The nodes run a traditional LAMP stack, with Nginx sitting in front of Apache as a proxy for static assets and for SSL termination. It also includes Xdebug pre-configured to connect to your IDE on the host machine.

System Requirements

  • Mac OS X 10.11 or later

  • An HFS+ Case-sensitive partition mounted at /Volumes/Server or /server

    Note: The environment should install and run from a case-insensitive mount, but this is not recommended for two reasons: a) the majority of deployments are done to case-sensitive file-systems, so development done on a case-sensitive mount is less error prone (ex: autoloaders may find a class in development, then fail on production); b) mysql will behave differently as it pertains to identifier case sensitivity potentially causing unexpected behavior

Environment Setup

  1. The install process will install brew on the host machine for gathering dependencies where not already present. If you already have brew installed, however, it is recommended to run the following commands, then cleanup any major issues it reports:

    brew update
    brew doctor
  2. Install technical dependencies and setup the environment, entering your account password when prompted (this may happen a few times):

    curl -s https://raw.githubusercontent.com/davidalger/devenv/master/vagrant/bin/install.sh | bash
    source /etc/profile
  3. Run the following to start up the virtual machine. This may take a while on first run

    cd /server
    vagrant up web72
  4. To SSH into the vm, you can use vcd or vcd web to connect and automatically mirror your working directory

Optional Steps

  1. Install the compass tools used for scss compilation

    sudo gem update --system
    sudo gem install compass
  2. Generate an RSA key pair. The generated public key will be used to authenticate remote SSH connections

    ssh-keygen -f ~/.ssh/id_rsa

    Note: When prompted, enter a memorable passphrase (you’ll need to use it later)

  3. Because of GitHub's rate limits on their API it can happen that Composer will silently fail when running the m2setup.sh tool. To prevent this from happening, create an OAuth token via the GitHub Settings area in your GitHub account. You can read more about these tokens here. Add this token to the composer configuration by running:

    composer config -g github-oauth.github.com "<oauthtoken>"
  4. Create a Magento 2 build available at m2.demo:

    vagrant ssh -- m2setup.sh --sampledata --hostname=m2.demo
    echo "10.19.89.14 m2.demo" | sudo tee -a /etc/hosts > /dev/null

Quick Reference

hostname ip role description
dev-host 10.19.89.1 host this is the host machine for the environment
[dev-web72] 10.19.89.16 app App node running PHP 7.2 / Percona Server 5.6
[dev-web71] 10.19.89.15 app App node running PHP 7.1 / Percona Server 5.6
[dev-web70] 10.19.89.14 app App node running PHP 7.0 / Percona Server 5.6

Virtual Machines

Web Application

This node is setup to run services required to run web applications. Nginx is setup to deliver static assets directly and act as a proxy for anything else. Apache is setup with mod_php to delivery the web application and sits behind Nginx on an internal port. Redis has been setup for a cache data store such that it never writes information to disk.

Run vhosts.sh to generate vhosts for all sites and reload apache. This will be automatically run once when the machine is provisioned, and may be subsequently run within the guest environment (use --help for available options).

The IP address of this node is fixed at 10.19.89.10. This IP should be used in /etc/hosts on the host machine to facilitate loading applications running within the vm from a browser on the host.

Virtual Host Configuration

Virtual hosts are created automatically for each site by running the vhosts.sh script. These .conf files are based on a template, or may manually be configured on a per-site basis by placing a .<service>.conf file in the root site directory where <service> is the name of the service the file is to configure (such as nginx or httpd).

To configure the virtual host configuration and reload services, run vhosts.sh within the guest machine. Running vhosts.sh --reset-config --reset-certs will wipe out all generated certificates and service configuration, creating it from scratch.

The vhosts.sh script looks for the pretense of three locations within each directory contained by /sites to determine if a given directory found in /sites is in fact in need of a virtual host. These locations are as follows:

  • /sites/example.dev/pub
  • /sites/example.dev/html
  • /sites/example.dev/htdocs

If any of these three paths exist, a virtual host will be created based on the template found in /server/vagrant/etc/httpd/sites.d/__vhost.conf.template. The DocumentRoot will be configured using the first of the above three paths found for a given site directory. The ServerName will match the name of the sites directory (example.dev above) and a wildcard ServerAlias is included to support relevant sub-domains. When a file is found at /sites/example.dev/.vhost.conf it will be used in leu of the template file. Any updates to this file will be applied to the host configuration on subsequent runs of the vhosts.sh script.

PHP Versions

  • PHP 7.2
  • PHP 7.1
  • PHP 7.0

SSL

When the web VM is provisioned, a root CA is automatically generated and stored at /server/.shared/ssl/rootca/certs/ca.cert.pem if it does not already exist. During vhost discovery and configuration, a wildcard cert, signed by the root CA, is automatically generated for it. Nginx is configured accordingly.

This means that all vhosts support SSL on both the naked domain and any immediate subdomain. Since these certs are all signed by the persistent root CA, if the root CA is added to the host as a trusted cert, the SSL cert for any vhost will automatically be valid.

Mac

To add the generated root CA to your trusted certs list on the host machine, run this command (after vagrant up has been run):

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /server/.shared/ssl/rootca/certs/ca.cert.pem
Windows

To add the generated root CA to your certificate manager on Windows you will need to copy the ca.cert.pem file to a location on your Windows system like C:\certs\ca.cert.pem and then open a Command Prompt window in Administrator mode to execute the following command

certutil –addstore -enterprise –f "Root" c:\certs\ca.cert.pem

Database Server

Each machine has an instance of Percona Server 5.6.x installed. Since this is a development environment, the root mysql password has been left blank. The data from the default machine is persisted in /server/mysql/data, data from other nodes persisted at /server/mysql/<NAME> where <NAME> is the name of machine the data is for.

To allow for custom database settings without modifying the default my.cnf file directly, files found at vagrant/etc/my.cnf.d/*.cnf will be copied onto this node and are applied via the !includedir directive in the /etc/my.cnf defaults file. Example use case: create the file vagrant/etc/my.cnf.d/lower_case_table_names.cnf with the following contents and then re-provision the vm:

[mysqld]
lower_case_table_names = 1

WARNING: Because data is persisted to the host machine via an NFS mount, attempts to forcefully shutdown (aka run vagrant destroy) a machine may cause data corruption and will fail subsequent mysql start operations unless the vm has first been halted and/or the mysql service stopped gracefully prior to vm destruction. The recommended sequence to wipe the vm and create from scratch is halt, destroy, then up.

Common Problems

Percona Server fails to start

When this happens you'll see something like the following when attempting to provision or boot the vm:

TASK [Starting mysql service] **************************************************
fatal: [web]: FAILED! => {"changed": false, "failed": true, "msg": "Starting MySQL (Percona Server). ERROR! The server quit without updating PID file (/var/lib/mysql/dev-web70.pid).\n"}

This happens (per above warning) when the mysql service fails to shutdown cleanly. To solve this issue, proceed through the following steps:

WARNING: If this is done and there is a running mysql instance using these ib* files, irreversible data corruption could occur. Please be careful!

  1. Verify that Virtual Box reports none of the virtual machines as still running. If machines are still running, you will need to halt each of them before proceeding.

    VBoxManage list runningvms | grep "Server_"
  2. Restart the rpc.lockd service on the host

    sudo launchctl unload /System/Library/LaunchDaemons/com.apple.lockd.plist
    sudo launchctl load /System/Library/LaunchDaemons/com.apple.lockd.plist

    Starting in MacOS 10.12.4 the rpc.lockd service is protected by System Integrity Protection, preventing you from reloading it via launchctl. If you see the message Operation not permitted while System Integrity Protection is engaged you will need to kill the rpc.lockd service instead. The service configuration has KeepAlive enabled, so the desired effect is accomplised, although in a much more heavy-handed fashion. Do this by running sudo kill <PID> where <PID> is replaced with the number lsof (per following step) displays under the PID column for the rpc.lockd command.

  3. Verify no locks exist on your ib* files (command should return nothing)

    sudo lsof /server/mysql/*/ib*
  4. Destroy and restart the virtual machine

    vagrant destroy -f
    vagrant up web72

If the above does not succeed in bringing it back online, try rebooting the host machine. If that still does not solve the issue, it is likely you will have to help mysqld out a bit with recovery. Check /var/log/mysqld.log for more info.

Development Notes

Session Storage

It is well recognized that PHP cannot store sessions on an NFS mount. Since /var/www/sites/ is mounted in the vm via an NFS mount, this causes trouble with storing session files inside the document root. Magento 2 seems to handle this just fine and stores it's sessions in the configured session location. Magento 1 requires a workaround to function.

To workaround this issue, replace the var/session directory with a soft-link pointing at the default php session store:

rm -rf var/session
ln -s /var/lib/php/session var/session

Alternately, you may use an alternative session storage mechanism such as redis or memcached to store sessions and avoid the problem altogether.

VMWare Provider

Using VMWare Fusion is a supported (but non-default) setup. There are additional steps involved to use it due to differences in how Virtual Box and VMX configure network interfaces and handle NFS mounts and you'll need to install a few additional dependencies manually.

Also note that the VMWare provider for vagrant requires an paid license in addition to the VMWare Fusion license you may already have.

To install additional dependencies, run the following commands:

brew cask install vmware-fusion vagrant-vmware-utility
sudo chown $(whoami) /opt/vagrant-vmware-desktop/

vagrant plugin install vagrant-vmware-desktop
vagrant plugin license vagrant-vmware-desktop <path_to>/license.lic

Finally, for NFS mounts to function, run the following to add the necessary exports to your /etc/exports file on the host machine and restart nfsd. Please note that the IP network range may be different on your machine. Use ifconfig to check on the vmnetX interfaces for the right IP range (If you haven't already, you'll need to attempt to start a VM for these interfaces to be created)

MAPALL="-mapall=$(id -u):$(grep ^admin: /etc/group | cut -d : -f 3)"
MOUNT_DIR="$(readlink /server || echo /server)"
printf "%s\n%s\n" \
    "$MOUNT_DIR/sites/ -alldirs -network 192.168.122.0 -mask 255.255.255.0 $MAPALL" \
    "$MOUNT_DIR/mysql/ -alldirs -network 192.168.122.0 -mask 255.255.255.0 $MAPALL" \
    | sudo tee -a /etc/exports > /dev/null
sudo nfsd restart

Start VMs enforcing use of the vmware_desktop provider by using something like the following:

vagrant up web71 --provider vmware_desktop

License

This project is licensed under the Open Software License 3.0 (OSL-3.0). See included LICENSE file for full text of OSL-3.0

devenv's People

Contributors

colnpanic avatar davidalger avatar ericthehacker avatar erikhansen avatar lordzardeck avatar rtull avatar tomispepe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

devenv's Issues

Nginx/MySQL timeout during long debugging sessions

I frequently use PhpStorm to debug an application and leave my debugging session open for 1hr+. The problem with this is that both MySQL and Nginx have such short timeouts that by the time I resume my debugging session, one or both of them have timed out.

I've temporarily resolved the MySQL timeout by adding this to my index.php file:

$timeout = 7200; // 2 hours
ini_set('mysql.connect_timeout', $timeout);
ini_set('default_socket_timeout', $timeout);

This solves the problem with MySQL terminating my debugging session, but since Nginx times out, I'm unable to see the results of the page load and instead see this:

screen shot 2015-11-06 at 4 22 04 pm

Since I can still complete my debugging process, I have not yet edited the Nginx file to increase the timeout, however I'm planning on doing that.

I'd like to implement a more permanent solution to this problem, as I expect I'm not the only one who runs into this issue. Would you accept a pull request that increases the MySQL and Nginx timeouts to 2 hours (or some other large value)?

I realize this could have negative implications for non-debugging situations, so maybe it would be better to have a standard way to temporarily increase the timeout and restart Nginx for the change to take effect.

Alternatively, maybe these settings could be triggered when a debug session is kicked off or at least when debugging is enabled (via the cookie or the xdebug.remote_autostart=on setting that the php-debug command sets). UPDATE: I don't like this approach. I think a specific script that temporarily changes these settings would be ideal.

Map certain host commands to wrapper script which runs command in VM

In order to ensure 100% consistent behavior, it could possibly be helpful to have certain commands configured on the host to be a shell script which hops inside the VM and runs the original command there.

These are some example such commands:

  • php (possibly restricted to only run in VM if under /sites, run on host overwise)
  • mr
  • composer

debugging nginx error

While debugging worked in PhpStorm, I ran into an issue where nginx decided it had waiting long enough and rendered an error on the page while I had the PhpStorm debugging session paused.

It looks like nginx is waiting about 60 seconds and then gives up, so if you haven't finished your debugging within 60 seconds nginx takes over and throws an error on the page.

PHP SOAP Extension

It would be nice to have the PHP SOAP extension included on the web vm.
extension=php_soap.dll

I expect this would be good to be part of the standard distribution because it's pretty common, and I have seen other common Magento extensions requiring it's presence.

Newer Magento 2 Installs Require bcmath

Ran into a Magento 2 installation issue that seems to be complaining about needing bcmath:

composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - videlalvaro/php-amqplib v2.5.2 requires ext-bcmath * -> the requested PHP extension bcmath is missing from your system.
    - videlalvaro/php-amqplib v2.5.1 requires ext-bcmath * -> the requested PHP extension bcmath is missing from your system.
    - videlalvaro/php-amqplib v2.5.0 requires ext-bcmath * -> the requested PHP extension bcmath is missing from your system.
    - Installation request for videlalvaro/php-amqplib 2.5.* -> satisfiable by videlalvaro/php-amqplib[v2.5.0, v2.5.1, v2.5.2].

After installing the php-bcmath package the issue was resloved:

sudo yum --enablerepo=remi --enablerepo=remi-php56 install php-bcmath

Host NFS Lock Clearing Details

Is there a shell script we could get that would clear the NFS locks, or a document that could be referenced on what is involved in restarting the services and anything else necessary to clear an NFS lock in the event that a VM crashed and locks are still maintained on the host.

Document and/or develop best-practice for optimum performance of ./var/ dirs

NFS write performance from within a VM is lacking (source: http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines). With the use of redis for the cache backend, this is primarily relevant to Magento 2 development due to it's use of ./var/ to store materialized assets and generated class files. So having a means of this information remaining native to the VM without breaking local development may be needed for M2.

Track run status of individual role provisioning scripts

The provisioner bootstrap should be capable of being re-run when a new provisioner is added to a machine role without attempt to execute all role scripts which may have already been run. Track the status of these runs within the vm to avoid duplicate runs and/or have these scripts include checks so the net result has no impact when already run.

Bash Autocomplete

The shell prompt inside virtual machines should have working autocomplete for common tools such as git.

Setup n98-magerun inside vm

The node role should provide the n98-magerun tool installed in /usr/local/bin and make it available to run either as n98-magerun and as simply mr

"Too many files open" error occurring frequently when running Magento 2

Every few days, I run into an issue where the /var/log/httpd/error_log file on my web node is filled with error messages like this:

[Thu Jan 14 21:07:45 2016] [crit] [client 127.0.0.1] (24)Too many open files: /server/sites/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

This is commonly caused when I delete the var/view_preprocessed and pub/static/frontend directories in my Magento 2 install and refresh.

The ulimit is currently set to 1024.It seems like the simple approach would be to raise the ulimit, however that may be treating the symptom, not the cause.

Change m2setup.sh to be verbose by default

There have been several times now where I've used the m2setup.sh script to install Magento where the script has silently failed for various reasons, but it's not apparent that the script has failed:

m2setup

sites_ _vagrant_dev-web__server_sites_ _ssh_ _vcd_ _105x49

I'd recommend changing the default behavior to verbose and then add a -q flag that can be used to suppress output.

Increase PHP session.gc_maxlifetime setting

The session.gc_maxlifetime setting is currently 1440 (24 minutes), which is the default PHP value. However this value should be increased in order to guarantee that Magento is able to have sessions that last longer than 24 minutes.

Classy Llama's standard value is 7200. Would you accept a PR to change session.gc_maxlifetime to 7200? Or do you have a different suggestion?

Add site specific configuration file to specify dependencies for spinning up vm

Requested by: @rtull

Currently all configuration is global and the only option is switching PHP versions (albeit manual). It would be nice to have a configuration file within a site directly allowing one to alter the vm dependencies, software versions, or add provisioners needed to operate given site. These should only be applied automatically if vagrant is run from within the site root or below.

Support offline machine initialization

Allow machines to be setup from scratch when the host machine is completely offline. This would only be expected to work when /server/.cache/ has already been primed via a previous machine setup. Certain things such as adding the Remi and MySql Community RPMs will need to be adjusted to work offline. At minimum, all scripts should be tested

Add https support in web machines

  • should create a CA root on host machine (in .shared) which user may then add to the system key trust store
  • virtual host template needs section added for secure requests
  • nginx will need to be configured to listen on 443 for secure requests, proxying all secure requests to apache (or support ssl termination in nginx layer as well for static assets)
  • vhosts.sh script should automatically sign a certificate (using shared CA root) for the virtual host when initially created

Hooks for vagrant commands

It would be nice to be able to have machine/user-specific scripts that would run based on different events such as vagrant up, vagrant suspend web, or vagrant up web. One use case that I'd use this for would be to automatically run the change-timeout.sh script every time the web or db VM was rebuilt.

This StackOverflow thread has some ideas for doing things like this: http://stackoverflow.com/questions/21476713/is-there-any-hook-like-pre-vagrant-up

Would you accept a PR that implements something like this?

Error screen when viewing m2.dev in browser after setup

After running the command, 'vagrant up', the following message is received in the browser window:

Autoload error:
Vendor autoload is not found. Please run 'composer install' under application root directory.

While running 'composer install' under the application root directory, prompts for your GitHub username and password, and downloads the files. After this operation is completed, the site displays an additional error message:

Error: Application is not installed yet.
NOTE: web setup wizard is not accessible.
In order to install, use Magento Setup CLI or configure web access to the following directory:` `/var/www/sites/m2.dev/setup
#0 /var/www/sites/m2.dev/lib/internal/Magento/Framework/App/Http.php(156): Magento\Framework\App\Http->redirectToSetup(Object(Magento\Framework\App\Bootstrap), Object(Exception))
#1 /var/www/sites/m2.dev/lib/internal/Magento/Framework/App/Http.php(136): Magento\Framework\App\Http->handleDeveloperMode(Object(Magento\Framework\App\Bootstrap), Object(Exception))
#2 /var/www/sites/m2.dev/lib/internal/Magento/Framework/App/Bootstrap.php(262): Magento\Framework\App\Http->catchException(Object(Magento\Framework\App\Bootstrap), Object(Exception))
#3 /var/www/sites/m2.dev/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#4 {main}

Running the following three commands corrects the issue:

rm -rf /sites/m2.dev/
vagrant destroy -f web
vagrant up

This has been tested on two machines.

mysql db import slowness

I've noticed that mysql imports tend to take a really long time so I started investigating a few different ways to import the database to the virtual machine.

This took 27 minutes to import a 180MB database.

pv /sites/m2esedev.dev/magento-database.sql | mysql -D test_import --default-character-set=utf8

This took 2 minutes to import the same file

vagrant ssh db -- 'mysql -uroot --password="" -D test_import --default-character-set=utf8 < /server/.shared/magento-database.sql'

I wanted to use pv to monitor large db import progress, and vagrant ssh appears to not work with pv. From what I was reading I think it's because the pv progress is reported to standard out and vagrant ssh is not reporting that back to the host. I decided to try it with the standard ssh client and pv works with that so I came up with this alternative.

This completed in 2 minutes and I got the progress from pipe viewer during import

pv /sites/m2esedev.dev/magento-database.sql | ssh dev-db 'mysql -uroot --password="" -D test_import --default-character-set=utf8'

In order to use the ssh command without specifying credentials on the command line like the vagrant ssh command I had to add ssh configuration options to my user account.

Host dev-db
  User vagrant
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /server/vagrant/.vagrant/machines/db/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

I don't understand why there is such a huge difference between executing the mysql import from the host machine, vs piping the file to the vm and executing it from within the virtual machine. It doesn't seem like it should be that slow when executed from the host.

Error after running 'vagrant status'

In Step 2, after running the command, 'vagrant status' the following messages are given:

==> host: Touching host indicator
==> host: Configuring /etc/profile for running sub-scripts
==> host: Linking /etc/profile.d -> /server/vagrant/etc/profile.d
Error: /etc/exports does not exist. See /server/README.md for details

Grunt support from within the VM

I wanted to use grunt from within the VM, but ran into a few issues when trying to install it. I got it working, but had to update the kernel-headers to support getting npm installed. That updated the kernel-headers from v2.2 to v2.6.

sudo yum install kernel-headers --disableexcludes=all
sudo yum install npm
sudo npm install -g grunt-cli

Install on new machine results in error when installing php56-redis

I just tried installing devenv on a new machine that did not previously have brew, php, or other primary dependencies installed and ran into an error that prevented me from continuing. I got this error when brew tried to install php56-redis:

==> Checking pack homebrew/php/php56-redis
==> Installing brew homebrew/php/php56-redis
Error: No such file or directory - /usr/local/opt/igbinary/include/igbinary.h

I ran the following commands (from this comment) and after doing so I was able to complete the devenv process.

brew remove php56-igbinary php56-redis 
brew reinstall php56 --enable-maintainer-zts --build-from-source php56-igbinary --build-from-source php56-redis --build-from-source

possible WSDL issue

Based on our conversation, due to the fact that the VM does not have custom host entries, it probably can't reach out to itself over HTTP.

Because of this, it's possible that this will break the Magento API, since Magento reaches out to itself over the network to get its WSDL file.

Symlink /var/www/sites to /sites

During VM provision, would nice to have /var/www/sites symlinked to /sites. This means that sites are at the same location inside the VM as outside.

Host php differs from vm client php

The default installed OS X version of PHP installed has some missing php extensions that are necessary for Magento 2.

I installed PHP 5.6 using brew and the associated php extensions as a workaround:

brew tap homebrew/dupes
brew tap homebrew/versions
brew tap homebrew/homebrew-php
brew install php56
brew install homebrew/php/php56-mcrypt
brew install homebrew/php/php56-redis
brew install homebrew/php/php56-intl

This lets me run bin/magento cache:flush, indexer:reindex, and setup:upgrade from the host, which is convenient.

m2.dev Script using symbolic links for var dir not working

I ran into an issue when setting up the m2.dev site in how it uses the symbolic linking for the var directories.

It worked fine from the browser, but if I tried to shell into the server and run bin/magento command from the console I had permission issues due to the fact that Apache was running as a different user than the vagrant user I logged into the shell with.

To resolve the issue I deleted the symbolic links and had Magento rebuild the var directories files under the /sites dir. I believe that because this is mounted through NFS, it forces permissions so they work for either Apache or the vagrant user.

Encoding issue (presumably) caused by Nginx proxy

When Nginx is sitting in front of Apache, any 404 page coming from Magento 2 results in 4 seemingly random characters prefixing the reply content and a \n0\n following it. See this diff between a request served directly from apache vs with nginx sitting between it and the end user:

diff --git a/a.txt b/b.txt
index ea968e8..edb035c 100644
--- a/a.txt
+++ b/b.txt
@@ -1,4 +1,4 @@
-dalger:01:42 PM:~$ curl -v http://m2.dev/foo
+dalger:01:51 PM:~$ curl -v http://m2.dev/foo
 *   Trying 10.19.89.10...
 * Connected to m2.dev (10.19.89.10) port 80 (#0)
 > GET /foo HTTP/1.1
@@ -7,8 +7,11 @@ dalger:01:42 PM:~$ curl -v http://m2.dev/foo
 > Accept: */*
 > 
 < HTTP/1.1 404 Not Found
-< Date: Thu, 24 Sep 2015 18:43:59 GMT
-< Server: Apache/2.2.15 (CentOS)
+< Server: nginx/1.0.15
+< Date: Thu, 24 Sep 2015 18:53:46 GMT
+< Content-Type: text/html; charset=UTF-8
+< Transfer-Encoding: chunked
+< Connection: keep-alive
 < X-Powered-By: PHP/5.6.13
 < Set-Cookie: PHPSESSID=<snip/>
 < Expires: <snip/>
@@ -21,10 +24,9 @@ dalger:01:42 PM:~$ curl -v http://m2.dev/foo
 < X-Magento-Cache-Control: max-age=86400, public, s-maxage=86400
 < X-Magento-Cache-Debug: MISS
 < X-Frame-Options: SAMEORIGIN
-< Connection: close
 < Transfer-Encoding: chunked
-< Content-Type: text/html; charset=UTF-8
 < 
+71d7
 <!doctype html>
 <html >
     <head >
@@ -505,3 +507,6 @@ require.config({"baseUrl":"http://m2.dev/static/frontend/Magento/blank/en_US"});
 </small>
 </div></footer></div>    </body>
 </html>
+
+0
+

Statamic is also falling prey to this depending on the content of the page and does not seem to be limited to 404 pages.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.