The Plack suite commonly uses the http://0:port. E.g. the following
plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root=>".");'
prints
HTTP::Server::PSGI: Accepting connections at http://0:5000/
However, the LWP::UserAgent (or some deeper called modules) didn't accepts it, e.g. the:
perl -MLWP::UserAgent -E '$u=LWP::UserAgent->new;$res=$u->get("http://0:5000/valid/path");print $res->status_line'
prints:
500 No Host option provided
but the
perl -MLWP::UserAgent -E '$u=LWP::UserAgent->new;$res=$u->get("http://localhost:5000/valid/path");print $res->status_line'
prints
200 OK
The question is: who is wrong?
Is the http://0:port valid, e.g. the LWP is "wrong"
or it isn't valid and the PSGI uses it as only "randomly valid" shortcut?
The output of the Plack suite is the output of a server. A server typically binds a socket to a certain port and address in order to serve content there.
The notation http://0:port means in this case: listen on port port on all addresses of this machine. This is handy if you don't know or don't want to specify all addresses of the machine where the server should be reachable.
The output of the LWP::UserAgent ist the output of a client. In order to open a connection to a server, you must explicitly specify the address and the port to connect to. 0 is no valid IP address, therefore the connection fails when you connect to http://0:port.
Safari 11, curl and wget resolve http://0:5000 to http://0.0.0.0:5000 and connect to the localhost.
I just tested it, after seeing the URL and finding the answer to the question dissatisfying.
Related
The Perl HTTP::Server::Simple::CGI sample code prints the following message:
Perl HTTP server message MyWebServer: you can connect to your server at http:// localhos t:8080
Does this mean the http server only receive http request from localhost?
How can I make it accept http from any host?
By default it binds to all interfaces.
However if you want to see if it really is, then you can use netstat.
netstat -an | grep -i listen
will show you what ports your machine is listening to. You should see something like:
tcp4 0 0 *.8080 *.* LISTEN
(for all interfaces).
Thanks for the response. Actually the perl http service works for both in-bound and out-bound. There was no filter of (localhost). The problem was the I used a port, which is not http default 80. The port was blocked by my desktop's firewall.
I have few doubts regarding telnet and echo which I haven't got so far lucky with google (also to say I have done my homework)
Does the telnet specification says that there are specific echo port and specific non-echo port?
If yes, Do ports 23 and 10001 differs on that specifically?
If conditional yes, is it some version of telnet protocol specific. In other words were those added after some specific iteration of telnet and/or are their fully compliant telnet clients and partially compliant one (regrading echo)?
also whats the difference if any between localecho and remote echo? I believe I am talking about echo from server side (remote echo?) but in any case which is what?
I am not sure if there is telnet / protocol specific child stackoverflow site? If yes, can somebody point me there?
The IANA Service Name and Transport Protocol Port Number Registry contains all port number registrations and for Telnet it cites RFC 854 as specification which defines
Port Assignment
When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.
For the Echo Protocol the RFC number RFC 862 which similarily defines
TCP Based Echo Service
One echo service is defined as a connection based application on TCP.
A server listens for TCP connections on TCP port 7. Once a
connection is established any data received is sent back. This
continues until the calling user terminates the connection.
The port number 10001 is registered for "SCP Configuration".
When a true Telnet server starts, it sends a number of IAC commands to the client telling it how to behave. The server can tell the client to do its own character echo (IAC DO ECHO) or it can tell the client to act dumb (IAC DONT ECHO). The client then confirms its action (IAC WILL ECHO) or inaction (IAC WONT ECHO). If the client responds the opposite of what the server requests then the server can either adapt or continue to insist (and likely eventually fail).
https://www.rfc-editor.org/rfc/rfc857
So to answer your specific question, no, there are not different echo/noecho ports. It's a result of server configuration and client capability. Though technically it is possible to have the telnet server have different configuration on different ports.
You can find a list of special Telnet codes and available do/dont/will/wont options here:
http://www.laynetworks.com/telnet.htm
I am getting the following from a script I am trying to run:
Notice: fwrite() [function.fwrite]: send of 7 bytes failed with errno=1 Operation not permitted in /home/thrawn/public_html/sorcero.us/MinecraftQuery.class.php on line 165
However, when I check phpinfo(), allow_url_fopen is on and Sockets Support is Enabled. I haven't been able to find anything pointing me to what might be causing this.
For clarification, I did not write this script. My knowledge of PHP is mostly just the basics, but I know enough to reason that this should be working since phpinfo() says the correct things are permitted. The script in question is here: https://github.com/xPaw/PHP-Minecraft-Query/blob/master/MinecraftQuery.class.php
fwrite() writes to $this->socket and is in private function WriteData(). In public function Connect() is a line
$this->Socket = #FSockOpen( 'udp://' . $Ip, (int)$Port, $ErrNo, $ErrStr, $Timeout );
This is the only line in this file where $this->socket is written.
Also, there is a warning message in the manpage for fsockopen()
UDP sockets will sometimes appear to have opened without an error,
even if the remote host is unreachable. The error will only become
apparent when you read or write data to/from the socket. The reason
for this is because UDP is a "connectionless" protocol, which means
that the operating system does not try to establish a link for the
socket until it actually needs to send or receive data.
This is probably the case. The socket is created although the ip adddress or the port is not reachable. This results in an error message when trying to write data.
So in order to resolve this, you would need to do at least these things:
Make sure the ip address and port are correct.
Verify that the server is up and running.
Make sure the ip address and port are reachable (not blocked in any firewalls)
I do not know what the correct settings should be. If you have installed the software on an external server, also try your local computer so you have a way to verify the ip address and port settings.
If you checked your PHP configuration and the problem persists, check your firewall log.
As Ignacio Vazquez-Abrams stated: this is an OS error.
In my case, CSF was blocking outgoing connections.
Seems like permission error,
Try,
chmod -R folder_to_be_file_written
Then execute php script
I would like to expose a service written in Perl to localhost HTTP requests. I do not want to modify Apache configuration. How to check whether a Perl CGI HTTP request originates from localhost?
I want for this check to succeed even if this call is made through a virtual host eg. https://www.myserivce.com/hidden/service.pl given that the call is made from inside of www.myserivce.com.
REMOTE_ADDR, but that's a dumb way to do it because you put the authentication logic in the application.
Instead, bind a stand-alone Web server to local interface only, thus the operating system's IP/networking stack guarantees that no request from outside can reach the server.
I think that if you put in /etc/hosts file an entry with myservice.com and ip 127.0.0.1 then all the requests from localhost to your site will have the REMOTE_ADDR set to 127.0.0.1 .
I am afraid that this is the only way to do it, unless you are making requests to 127.0.0.1/hidden/service.pl instead of myservice.com/hidden/service.pl
I have used the following code:
my $server_addr = inet_ntoa(scalar gethostbyname(hostname() || 'localhost'));
my $call_addr = $query->remote_addr();
die unless $call_addr eq "127.0.0.1" || $call_addr eq $server_addr;
I do not think it covers all cases, but seems to work with my setup. If anybody knows a generic solution then please submit it here.
Assuming the following is defined in .../hosts:
127.0.0.1 localhost
What, if any, are the actual differences between using 127.0.0.1 and localhost as the server name, especially when hitting processes running locally that are listening for connections?
Well, the most likely difference is that you still have to do an actual lookup of localhost somewhere.
If you use 127.0.0.1, then (intelligent) software will just turn that directly into an IP address and use it. Some implementations of gethostbyname will detect the dotted format (and presumably the equivalent IPv6 format) and not do a lookup at all.
Otherwise, the name has to be resolved. And there's no guarantee that your hosts file will actually be used for that resolution (first, or at all) so localhost may become a totally different IP address.
By that I mean that, on some systems, a local hosts file can be bypassed. The host.conf file controls this on Linux (and many other Unices).
Wikipedia sums this up well:
On modern computer systems, localhost as a hostname translates to an IPv4 address in the 127.0.0.0/8 (loopback) net block, usually 127.0.0.1, or ::1 in IPv6.
The only difference is that it would be looking up in the DNS for the system what localhost resolves to. This lookup is really, really quick. For instance, to get to stackoverflow.com you typed in that to the address bar (or used a bookmarklet that pointed here). Either way, you got here through a hostname. localhost provides a similar functionality.
some applications will treat "localhost" specially. the mysql client will treat localhost as a request to connect to the local unix domain socket instead of using tcp to connect to the server on 127.0.0.1. This may be faster, and may be in a different authentication zone.
I don't know of other apps that treat localhost differently than 127.0.0.1, but there probably are some.
Well, by IP is faster.
Basically, when you call by server name, it is converted to original IP.
But it would be difficult to memorize an IP, for this reason the domain name was created.
Personally I use http://localhost instead of http://127.0.0.1 or http://username.
There is nothing different. One is easier to remember than the other. Generally, you define a name to associate with an IP address. You don't have to specify localhost for 127.0.0.1, you could specify any name you want.