Sending out web pages without an invitation

Dennis wrote:

 > the Server will send out a new page to Computer #1 even though
 > Computer #1 didn't request anything.

Not possible. Sorry.

However, you could use the meta refresh header to get computer #1
to automatically refresh the page every X number of seconds and
after computer #2 has done its stuff send a different page to
computer #1 on the next refresh.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ <a style='text-decoration: underline;' href="http://tobyinkster.co.uk/contact" target="_blank">http://tobyinkster.co.uk/contact</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

On Wed, 29 Sep 2004 19:50:39 +0100, Toby Inkster
<usenet200409.DeleteThis@tobyinkster.co.uk> wrote:

 > Dennis wrote:
 >
  >> the Server will send out a new page to Computer #1 even though
  >> Computer #1 didn't request anything.
 >
 > Not possible. Sorry.

That's not entirely accurate. If you can set up a listening port on
Computer #1, and then send the page to that port, Computer #1 can recieve
the page and perform operations on it, even though it was never
requested. Requires that you have port-opening access to Computer #1
though.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollory that nothing is ridiculous.
- <a style='text-decoration: underline;' href="http://www.greywyvern.com" target="_blank">http://www.greywyvern.com</a> - Orca Knowledgebase: Completely CSS styleable
Knowledgebase/FAQ system<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

GreyWyvern wrote:

 > Requires that you have port-opening access to Computer #1 though.

And how many computers are configured to allow random web servers to open
up their ports?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ <a style='text-decoration: underline;' href="http://tobyinkster.co.uk/contact" target="_blank">http://tobyinkster.co.uk/contact</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

On Wed, 29 Sep 2004 20:15:12 +0100, Toby Inkster
<usenet200409.TakeThisOut@tobyinkster.co.uk> wrote:

 > GreyWyvern wrote:
 >
  >> Requires that you have port-opening access to Computer #1 though.
 >
 > And how many computers are configured to allow random web servers to open
 > up their ports?

*That's* not possible, but having a listening port would be the only way
to do it. It could be useful if the administrators of *both* systems were
setting up an automatic mirror. If the source computer initiates the
transfer, it eliminates the possibility of the mirror attempting to mirror
and getting a server down message. It would also allow the source
computer to schedule when it mirrors, like during times of low traffic.

In a normal, everyday user context, you're right. However, I don't see
the use of such a system. What would it do, beep: "You've got HTML!" and
pop up your browser? Imagine the headaches due to annoyance! It's not
that it's not possible, but without permission it's not allowed This
second option seemed a silly thing to ask so I assumed the first by
default.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollory that nothing is ridiculous.
- <a style='text-decoration: underline;' href="http://www.greywyvern.com" target="_blank">http://www.greywyvern.com</a> - Orca Knowledgebase: Completely CSS styleable
Knowledgebase/FAQ system<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

On Wed, 29 Sep 2004 20:15:12 +0100, Toby Inkster
<usenet200409 DeleteThis @tobyinkster.co.uk> wrote:

 >GreyWyvern wrote:
 >
  >> Requires that you have port-opening access to Computer #1 though.
 >
 >And how many computers are configured to allow random web servers to open
 >up their ports?


Toby and Grey:

Continual automatic refresh at a designated interval ---that's exactly
the sort of work around that'll let me pull this off. I was thinking
along the lines of some sort of "web page level" instant messaging or
"automatic" virtual private network connection. But the auto refresh
approach I think will work out fine. I didn't know you could do that.

Thanks for your thoughts.

Dennis<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

Postscript for posterity (eg, for me when I forget all this after 2
years and need to do a google search for it) and anyone else:

The auto refresh business isn't completely robust --some browsers
don't support it, some will flicker at each refresh, and the back
button can register each refresh as a separate web page --according to
what I've read.

But searching further on auto refresh turned up a thing called "server
push." This is where a server sends out a page to a client "without
an invitation" as I was hoping for. A java applet CAN receive a
server push so that's probably the cleanest way to go.

(Is it bad netiquette to leave messages for yourself for future use
this way? Shades of Memento and Myst...)

Dennis

 >On Wed, 29 Sep 2004 20:15:12 +0100, Toby Inkster
 ><usenet200409.TakeThisOut@tobyinkster.co.uk> wrote:
 >
  >>GreyWyvern wrote:
  >>
   >>> Requires that you have port-opening access to Computer #1 though.
  >>
  >>And how many computers are configured to allow random web servers to open
  >>up their ports?
 >
 >
 >Toby and Grey:
 >
 >Continual automatic refresh at a designated interval ---that's exactly
 >the sort of work around that'll let me pull this off. I was thinking
 >along the lines of some sort of "web page level" instant messaging or
 >"automatic" virtual private network connection. But the auto refresh
 >approach I think will work out fine. I didn't know you could do that.
 >
 >Thanks for your thoughts.
 >
 >Dennis<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

You're right. That's the implication. Advertisers would have a field
day. I guess there's some code in browsers that will only permit them
to receive pages that they have requested. But, it just occured to
me, if a browser requests a SPECIFIC PAGE from a server, what would be
the harm in letting the server send that browser that SAME PAGE more
than once (assuming the browser didn't request another page in the
interim)? Maybe current browsers COULD accept such a page. So I'm
back to my original question, how could I get a server (what server
side code) to send a page out to some IP address I have in my
database?

Just when I thought I had this wrapped up.

Dennis

On Wed, 29 Sep 2004 12:22:06 -0700, "Augustus"
<Imperial.Palace.TakeThisOut@Rome.com> wrote:

 >
 >"Dennis" <theOnlyWho.TakeThisOut@mindspring.com> wrote in message
 >news:iosll09jjug0tj9o3ks80qm2venk7p3270@4ax.com...
  >> Greetings to everyone:
  >>
  >> If someone could point me in the right direction on this I'd really
  >> appreciate it. Here's what I'm trying to do:
  >>
  >> Computer #1 requests a web page from a Server, and the Server sends
  >> the page. In a table on the server, the IP address of the Computer #1
  >> is saved. Later, Computer #2 requests a page from the same Server.
  >> Now, if the web page Computer #2 requests meets certain conditions,
  >> the Server will send out a new page to Computer #1 even though
  >> Computer #1 didn't request anything. I'll be OK with the php and
  >> mysql part of this, but I don't know I could just shoot someone out a
  >> web page "spontaneously" from my Server. Is this possible?
 >
 >No.
 >
 >If you think of the implications, it makes sense: If one could do it, then
 >they all could do it... meaning you get home and turn on your computer and
 >open your browser and then people just start feeding you pages that you
 >aren't requesting...it would just be a non stop stream of ads that you
 >couldn't read because everybody is sending you a new page to your browser.
 >
 >I'm suspecting you have an idea about something you want to do where this
 >might seem like the solution, but if you elaborated people might be able to
 >expand upon it and give you alternatives
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

Dennis wrote:

 > I guess there's some code in browsers that will only permit them
 > to receive pages that they have requested.

You really don't understand how HTTP works do you?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ <a style='text-decoration: underline;' href="http://tobyinkster.co.uk/contact" target="_blank">http://tobyinkster.co.uk/contact</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

On Fri, 01 Oct 2004 22:40:38 +0100, Toby Inkster
<usenet200409 DeleteThis @tobyinkster.co.uk> wrote:

 >Dennis wrote:
 >
  >> I guess there's some code in browsers that will only permit them
  >> to receive pages that they have requested.
 >
 >You really don't understand how HTTP works do you?

That's fair to say, but I know it must be logical. Logically --or,
better, functionally-- a client sends out some information to a server
(a web page request), and then, some time later, the server sends out
some information (a web page) back to the client. The two know where
each other lives. What prevents a client from receiving information
(and displaying a web page) from a server that it didn't request
information from?

Dennis<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation 

Dennis wrote:

 > That's fair to say, but I know it must be logical. Logically --or,
 > better, functionally-- a client sends out some information to a server
 > (a web page request), and then, some time later, the server sends out
 > some information (a web page) back to the client.

That's not really how it works.

The client initiates a TCP connection with the server. A TCP connection
can be thought of as a pipe with two ends. (To continue the pipe analogy,
you can think of all computers as having thousands of numbered holes in
them called "ports", and that you can connect up pipes to the ports. The
ports also have valves on them allowing them to be opened and closed. When
they're closed, no pipes can be connected to the port.)

One end is connected to port 80 of the web server, which was sitting
there left open, waiting for people to connect to it. The other end of the
pipe is connected to a randomly-selected unused port on the client, which
had been closed, but was opened by the web browser for this special
purpose.

Now a pipe connection has been established between the two computers. The
browser writes a note on a bit of paper requesting a file and pushes it
down the pipe. The server reads the request and puts its response on
another bit of paper and pushes it back down the pipe in the opposite
direction. The client recieves the response and closes that
randomly-selected port. And because pipes can't be connected to closed
ports, the pipe magically disappears.

Now think about it -- how can the server push another response back to the
client? The original pipe has disappeared. It could try connecting another
pipe up, but the port it used before is now closed. It could look for
another open port on the client, but there's no guarantee that if it sent
a piece of paper to a different port that it would be collected by the
browser at the other end, and not by some other bit of software, like some
mail serving software that would just be confused about getting a random
web page.

The only way it can be done is if the client has some software running
that opens up a predetermined port and sits there waiting for a web page
to be sent into the port -- which is what GreyWyvern suggested.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ <a style='text-decoration: underline;' href="http://tobyinkster.co.uk/contact" target="_blank">http://tobyinkster.co.uk/contact</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Sending out web pages without an invitation