-
All replies
-
Helpful answers
-
Dec 26, 2015 2:44 PM in response to Aie aie aie !by MrHoffman,★HelpfulFundamentally no. Two different TCP servers cannot use the same port at the same time. That's a basic conflict.
OS X ships with Apache, and that works fine. OS X Server provides tools to configure, manage and extend the Apache environment. Add-on packages such as MAMP or AMPPS or XAMPP each provide their own Apache versions, and other bits.
Most web servers can be started on a variant port, and that's generally easier with the add-on package, and not the integrated Apache server within OS X.
OS X Server is fairly rarely used on laptops, as OS X Server generally works best with static IP addresses, and laptops generally roam around and thus usually have DHCP dynamic IP addresses.
TL;DR: Use the standard port and a virtual host, or use the standard web server or an add-on server on a variant port.
-
Dec 26, 2015 2:51 PM in response to MrHoffmanby Aie aie aie !,Thank you MrHoffman !
That being said, would there be a way to bypass this conflict or to find a solution using a tool or software ?
Would port forwarding be of any help ?
The problem I encounter now after this conflict is that ampps won't want to work anymore because apple server makes it so that apache won't start on ampps, apparently.
I wanted to use ampps for dev and server for web diffusion of my sites developped on local environment. Would you know an alternative to help me accomplish this using mostly or only open source solutions ?
-
Dec 26, 2015 3:24 PM in response to Aie aie aie !by MrHoffman,You want to use two different web servers on one system.
You want to use a server for development.
You want these two different web servers to share the same underlying network, and to share the same TCP socket end-point for incoming network connections from local and remote web clients; from the web browsers.
Unfortunately for your goals, the fundamental nature of a TCP socket is that there's one process listening at a time. Multiple listeners involve all of the processes posting reads on the socket, and whichever process reads the arriving data goes off and processes it. Which process that might be — which web server — is indeterminate. This means that your data — if you tried sharing the sockets — would be rather confusing, with data going to whichever server happened to have the fastest read I/O request.
Again, different web servers either need to operate on different ports (8080 is a common choice, here), or you need to shut down one web server and switch over to the other when you want to use the other web server on TCP port 80. Or use separate systems, or separate guests virtual machines.
Port forwarding is a process of mapping network traffic that is transitioning through some particular network device or network firewall, with either a general request to forward the external connection through to the same port, or to perform port remapping, and that usually based on some detail "visible" to the device or the server that's performing the port forwarding. This might map all traffic, or it might use the source address of the connection. If you're running this whole environment locally on one box and connecting to the host, then that local address as the originating address would map all traffic to some other port — this whether developer traffic or something else connecting to TCP port 80 — and which is a whole lot of effort, particularly when the specification of the port in the URL is directly available. That is, instead of doing a whole pile of mapping, just specify http://www.example.com/ (which will default to TCP port 80) and http://www.example.com:8080/ (which explicitly requests whatever server is running on TCP port 8080).
Configure the web servers to use different ports — MAMP or AMPPS or XAMP are what I'd reconfigure, and not the OS X integrated Apache web server — or use separate guests in local virtual machines, or shut down and switch web servers, or use a different virtual host in Apache and a different path on the local system.
Since you're working as a web developer, some knowledge of how web servers work, and about how TCP and sockets work, as well as how HTML5 features such as websockets work, and related topics such DNS and proper use of TLS, can really help you differentiate your skills and your abilities from those web developers that don't understand how all these pieces fit together (correctly and securely), too.