Re: Accessing web with a C program



rlb@xxxxxxxxxxxxxxxxxxxxxx (Richard Bos) writes:
"Lew Pitcher" <lpitcher@xxxxxxxxxxxx> wrote:

On Feb 8, 3:40 pm, Christopher Benson-Manica
<a...@xxxxxxxxxxxxxxxxxxx> wrote:
Lew Pitcher <lpitc...@xxxxxxxxxxxx> wrote:
You /should/ be able to
FILE *web = fopen("http://google.com/","r";);
and have a valid read connection to the named web page.

Should? I'm curious, what argues for this behavior? I certainly
wouldn't expect it from fopen() regardless of whether it was commonly
implemented or not.

What sort of behaviour would you expect from
FILE *somefile = fopen("C:\\ABC\\DEF\\GHI.J","r");
or
FILE *somefile = fopen("DDNAME:SYSIN,"r");
or
FILE *somefile = fopen("/a/b/c.d","r");

I'd expect it to open a local file.

How do you know that "/a/b/c.d" is the name of a local file? It could
well be stored on some server somewhere and accessed via NFS or some
other protocol.

This is very different from opening a URL, because that involves making
a connection to a random machine on the 'net, and possibly getting the
user to enter dialing passwords and all.

It's not obvious that fopen() should support the NFS protocol but not
the HTTP protocol. There is a difference in that an HTTP name (a URL)
specifally names the remote server -- but some systems, including VMS,
have file names that do the same thing but are expected to be treated
as ordinary files.

It's also possible, on some operating systems, to create a filesystem
that maps URLs to what appear to be local file names. On such a
system, fopen("http://google.com";, "r") would invoke code in the
filesystem driver that would access google.com using the HTTP
protocol, but that would be invisible to the program that calls
fopen(). Given this capability letting fopen() accept URLs directly
is just a matter of doing the net access at a different level.

Of course, you have to draw the line somewhere. The usual practice is
*not* to treat URLs as file names. In my opinion, that's not a bad
place to draw the line, but I don't see any strong arguments for or
against drawing it somewhere else.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.



Relevant Pages

  • Re: HTTPhandlers
    ... debates weather or not HTTP is a suitable protocol is not what I am looking ... I need to know how I can have a TcpListener listen on port 80 eventhough IIS ... > which you make the request to do the connection with the user and maintain ... >> HTTP is a stateless protocol. ...
    (microsoft.public.dotnet.framework)
  • Re: Connection(less) to a remoting server
    ... no, http traffic negotiates a connection before submission occurs, it is ... therefore a connected protocol - udp would use disconnected. ... negotiates between your client to the remoting server - thats why http over ... in that no permanent connection is ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Wrapping TCP communications in HTTP
    ... If your protocol is half-duplex, you can tunnel it using a single ... persistent connection to the HTTP server. ... one for receiving (by constantly polling the server for messages). ... > we would like to wrap these communications in the HTTP protocol. ...
    (microsoft.public.win32.programmer.networks)
  • Re: SSL vs. SSL over tcp/ip
    ... that were at different places in the internet backbone ... hierarchical routing (part of the problem was anarchy routing was ... that was only true once the connection was made. ... kernels and tcp/ip protocol stack ... ...
    (comp.security.misc)
  • More info (Re: ppp dialin problems: mgetty and ppp.conf)
    ... connection to the Internet, however, it appears that if I maintain the ... slots with slot compression ... 0x8057 (Internet Protocol V6 Control Protocol) was rejected! ...
    (freebsd-questions)