---
# System prepended metadata

title: Web Server Re-architecture

---

# Web Server Re-architecture
<!--- Provide a general summary of the request in the Title above -->

## Describe the Enhancement
<!--- Explain the change you'd like to see. Include information about how the buildpack works now and how you envision it to work after this change. -->
RFC(link) has been accepted and merged. This is a tracking issue for implmenting this work.

## Step 1 - Development backwards compatibility
In order to allow for the development of new buildpacks such as `<web-server>-zero-configuration` and `<web-server>-start` we will need a buildpack that can provide the `web-server` in question without doing any other configuration. In order to achieve this I propose the `nginx` and `httpd` buildpacks each respectively utilize a new provision `nginx-development` and `httpd-development` or'd to the existing buildpack. The new buildpacks will be able to require the development provisions and when the `<web-server>` buildpack detects that a development provision was required it can modify it's build process to only provide the `<web-server>` dependency. This will also have the advantage of isolating the provision steps in build which will be useful when those parts are the only ones that will be needed in the buildpack going forward. This API will allow the buildpack to continue to function as it normally would but allow buildpacks to be developed using the future expected behavior.

- [ ] issue (Add development provision to nginx)
- [ ] issue (Add development provision to httpd)

## Step 2 - Develop new buildpacks
The new buildpacks that cover existing functionality in the `<web-server>` buildpacks such as zero configuration and writing start commands are being exported to new buildpacks. These need to be written and tested in the same way that they are in the current `<web-server>` buildpacks.

### Nginx
- [ ] issue (Create nginx-zero-configuration)
- [ ] issue (Create nginx-start)

### HTTPD
- [ ] issue (Create httpd-zero-configuration)
- [ ] issue (Create httpd-start)

## Step 3 - Convert existing buildpacks and update API
Once the new buildpacks are developed the existing `<web-server>` buildpacks can be converted into their new role and dependency providing buildpacks. The development API can also be removed at this stage and the developed buildpacks can swap over.

### Nginx
- [ ] issue (Convert nginx to dependency buildpack)
- [ ] issue (Update nginx-zero-configuration build plan API)
- [ ] issue (Update nginx-start build plan API)
- [ ] issue (Update language family nginx order groupings)


### HTTPD
- [ ] issue (Convert httpd to dependency buildpack)
- [ ] issue (Update httpd-zero-configuration build plan API)
- [ ] issue (Update httpd-start build plan API)
- [ ] issue (Update language family httpd order groupings)

## Motivation
This will make the `web-server` buildpacks more similar to existing buildpack ecosystems and will make the dependencies easier to utilize by other buildpack families.