Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: Systems and methods for handling idle websites on a Web server are disclosed. The duration between requests for a website application is monitored and compared to an idle time-out value. The idle time-out value may be a user-selected value that is the same for all website applications or an idle time-out value selected for a group of worker processes. When the idle time-out value is reached, all inactive memory allocations for the website application are paged-out. When a request for the website application is later received, memory for the website application is paged-in so that the request can be processed.

Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: Systems and methods for handling idle websites on a Web server are disclosed. The duration between requests for a website application is monitored and compared to an idle time-out value. The idle time-out value may be a user-selected value that is the same for all website applications or an idle time-out value selected for a group of worker processes. When the idle time-out value is reached, all inactive memory allocations for the website application are paged-out. When a request for the website application is later received, memory for the website application is paged-in so that the request can be processed.

Abstract: Systems and methods for handling idle websites on a Web server are disclosed. The duration between requests for a website application is monitored and compared to an idle time-out value. The idle time-out value may be a user-selected value that is the same for all website applications or an idle time-out value selected for a group of worker processes. When the idle time-out value is reached, all inactive memory allocations for the website application are paged-out. When a request for the website application is later received, memory for the website application is paged-in so that the request can be processed.

Abstract: Systems and methods for handling idle websites on a Web server are disclosed. The duration between requests for a website application is monitored and compared to an idle time-out value. The idle time-out value may be a user-selected value that is the same for all website applications or an idle time-out value selected for a group of worker processes. When the idle time-out value is reached, all inactive memory allocations for the website application are paged-out. When a request for the website application is later received, memory for the website application is paged-in so that the request can be processed.

Abstract: Embodiments disclose a reverse lookup using an IP:Port-to-hostname table to identify a hostname when only an IP address and port is present in an SSL hello connection, which may occur, for example, when a non-SNI-capable client initiates the SSL hello. Once the hostname is successfully looked up, a naming convention is used to simplify the management and identification of SSL certificates. Different types of SSL certificates are supported. Multiple hostname matches may be associated with a given IP address and port in the IP:Port-to-hostname table. In such case, the first-matching hostname is always used with the naming convention to identify related SSL certificates. The naming convention is applied in such a way that it will first look for the most matching file name to the least matching file name.

Abstract: A web application may be developed in an environment which has different components than a target environment, so determining component dependencies and identifying which dependencies are met in a given environment can be helpful when deploying the application. Toward that end, test code makes a request that test file(s) be sent from a protected location in the target environment, such as from a randomly-named folder or from another location that is not directly browsable by a user. Received test file(s) and network protocol headers are parsed, and component dependency metadata such as component names and version numbers are extracted. Based on the extracted metadata, information is determined about the target environment's installed component(s). By comparing component dependency(ies) of the program with the identified installed component(s) of the target environment, compatibility of the target environment can then be reported.

Abstract: Embodiments disclose a reverse lookup using an IP:Port-to-hostname table to identify a hostname when only an IP address and port is present in an SSL hello connection, which may occur, for example, when a non-SNI-capable client initiates the SSL hello. Once the hostname is successfully looked up, a naming convention is used to simplify the management and identification of SSL certificates. Different types of SSL certificates are supported. Multiple hostname matches may be associated with a given IP address and port in the IP:Port-to-hostname table. In such case, the first-matching hostname is always used with the naming convention to identify related SSL certificates. The naming convention is applied in such a way that it will first look for the most matching file name to the least matching file name.

Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: A web application may be developed in an environment which has different components than a target environment, so determining component dependencies and identifying which dependencies are met in a given environment can be helpful when deploying the application. Toward that end, test code makes a request that test file(s) be sent from a protected location in the target environment, such as from a randomly-named folder or from another location that is not directly browsable by a user. Received test file(s) and network protocol headers are parsed, and component dependency metadata such as component names and version numbers are extracted. Based on the extracted metadata, information is determined about the target environment's installed component(s). By comparing component dependency(ies) of the program with the identified installed component(s) of the target environment, compatibility of the target environment can then be reported.