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

mapping certain extensions (e.g. .php) to FastCGI #357

Closed
kazuho opened this Issue Jun 10, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@kazuho
Member

kazuho commented Jun 10, 2015

Many PHP-based apps (esp. those designed for Apache + mod_php) stores .php files under document root, expecting that the web-server would determine by looking at the extension if the content should be served statically or if it should be served dynamically (by executing the file).

We would definitely want to do the same in H2O by using php-fpm.

relates to #346

@kazuho kazuho added the enhancement label Jun 10, 2015

@gaoyichuan

This comment has been minimized.

Show comment
Hide comment
@gaoyichuan

gaoyichuan Jun 10, 2015

Well, why not implement some kind of the nginx style? (such as config of location)

gaoyichuan commented Jun 10, 2015

Well, why not implement some kind of the nginx style? (such as config of location)

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Jun 10, 2015

Member

Well, why not implement some kind of the nginx style? (such as config of location)

If you are talking about using pattern-matching against URL to detect requests to PHP files, I would say that such approach is broken by design.

If you Google, you would find lengthy discussions on how to mimic extension-based mapping of php files on nginx by using directives like try_files, fastcgi_split_path_info, fastcgi_index, etc., and no one is sure what the ideal configuration is.

I do not want to create such a configuration mess with H2O; FastCGI (or PHP) applications should be as easily configurable as it is for the Apache HTTP server; and the logical approach is to support extension-based mapping (which was how Apache was designed / is also what RFC 3875, which FastCGI is designed upon, expects).

Member

kazuho commented Jun 10, 2015

Well, why not implement some kind of the nginx style? (such as config of location)

If you are talking about using pattern-matching against URL to detect requests to PHP files, I would say that such approach is broken by design.

If you Google, you would find lengthy discussions on how to mimic extension-based mapping of php files on nginx by using directives like try_files, fastcgi_split_path_info, fastcgi_index, etc., and no one is sure what the ideal configuration is.

I do not want to create such a configuration mess with H2O; FastCGI (or PHP) applications should be as easily configurable as it is for the Apache HTTP server; and the logical approach is to support extension-based mapping (which was how Apache was designed / is also what RFC 3875, which FastCGI is designed upon, expects).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment