Re: Banana Republic (was Re: OpenVMS Book Wins award)

Richard Maher wrote:
Hi Mark,

Thanks for the reply.

I bought it through Barnes and Noble in late May '08 for US$36.00 plus
US$13.00 P&P, and I think my credit card statement said something like
AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
at US$0.65 now escapes me - perhaps that's one reason I'm still working
for wages.

I looked seriously at Perth Mint gold in August (when the bank deposit
guarantee was sweet FA) and Foreign Currency accounts aren't as common here
as they are in the UK. Either way I would (and have) lost big time - but
haven't we all :-(

That any network connectivity has some sandboxing doesn't exactly
surprise me.

Me either! I'm a big fan of the same-origin, or codebase, policy for Applets
but these guys just want to keep pushing the envelope.

I noted the post on Adobe policy files.

A network conduit (like SSH or HTTP CONNECT) is carte
blanche for whatever the agent wishes to transfer. No constraint would
be considered negligence.

Yeah, but here I bow

;-)

to your much greater experience and ask "What the hell
can a *Socket not HTTP* proxy-server do for me?".

Isn't a(n IP) socket proxy that doesn't explicitly talk HTTP during setup a one-to-one NAT router? And if accepting external connection requests, a static port mapping NAT router, into/through the DMZ and onto internal services? And so forth through the NAT variants.

Look I wanted a HTTP
CONNECT handshake to give me a Tunnel for my Socket over a httpS connection
to an arbitray TCP/IP server, but it doesn't look doable; please advise.

I can but reframe my previous comment; unconstrained connectivity from browser based applications is surely like signing a full book of blank cheques.

I also view with interest what the Comet guys are doing with Orbited (see
www.cometdaily.com for some background) as they don't seem to be bound by
(or have already solved) these proxy-server restrictions.

AIUI; Orbited is a service used to accept Web-style socket connection requests from browsers, establish Comet-style, bidirectional communication with the browser, then proxy (or forward, or gateway, or <whatever-you-feel-comfortable-describing-it-as>) that communication via a TCP socket to the requested end-point. Without some sort of access control it functions as an open relay - carte blanche. With access control it's a lot like most CONNECT proxy, or at least CONNECT reverse-proxy. Of course it's a bit more than that (but isn't everything!) Until Web Sockets become commonplace it uses a number of approaches to *emulate* asynchronous comms with current browsers.

AIUI; Comet is a broad term used to described leveraging HTTP server-push of unsolicited/unpolled/asynchronous data to the browser, using existing HTTP technologies, most commonly, though not restricted to, streaming of a series individual response data 'inside' a persisting HTTP connection, currently via 'long polling' and XMLhttpRequest() or <script> tag instances. It's a compromise hack. Not perfect but it works. Of course it's more than this (but then isn't everything!) Undoubtably it will(/is) develop(ing) to encompass Web Sockets, etc.

Both are broad, evolving concepts and implementations.

FYIW; I have an (as-yet) unpublished Web application displaying elementary graphs of $GETRMI (monitor) data. It uses a Comet-style <IFRAME> and streaming long-poll. When system data changes it generates a <script>ed function call into browser JavaScript that supplies data values which the application JavaScript then graphs or displays. One buffered I/O of a few tens to a few hundreds of bytes (depending on what data have changed) per sample period. Negligible CPU ticks. Not full-duplex but not synchronous-poll either.

I'm guessing you mention this because the suggestion below that

"that the time could be better spent providing guidelines for
communication via an asynchronous CGI [originally I read GUI :-]
interface."

sounds remarkably like Tier3 :-)

Damn, I'm as transparent and one-domensional as usual :-)
>
The way I see it is we have two camps (and I'm happy to live with the
pluralism and think there's enough room for everyone).

1) The WebSockets http/html5 guys who have the distinct (and only) advantage
of being able to tunnel out of 80/443 as HTTP

If you mean, provide asynchronous (event triggered), binary (non-HTTP) comms using these ports then yes. Of course there is no reason why the services requested over these ports cannot further proxy the binary to TCP anything-configured. IMO the bottom line is (again) access-control. Whether this is the lone advantage is moot.

Of course Web Sockets require specialised server (and proxy server) as well as client (browser) support.

The WASD mudmap includes Web Sockets server support (either 10.0 in mid-'09, or 10.1 in mid-'10). Perhaps once HTML5 moves from draft :-}

2) The New Order of full-blown, connection-oriented, full-duplex, binary,
Socket Interaction

No doubt this will be remarkably versatile in the absence of sandboxing, with many-and-varied conduits established between user's browsers and all manner of 'services'.

If Sockets can't traverse public proxy-servers with existing HTTP then
option 1 is no longer on the table as far as I can see?

This one has lost me but I'll have a go at two of the possible intents:

1) If you mean Web Sockets can't through existing HTTP proxy then the answer seems to me that they are designed to do just that. Web Sockets behind proxy servers know it and appropriately CONNECT to tunnel.

2) If you mean TCP sockets can't then no, unless they speak the application-level protocol required by the proxy (which would make them Web Sockets for all intents and purposes :-)

Anyway, please let me ask the question of why anyone would want to use a
proxy-server for Socket communication?

. Socket Cacheing - No Thanks

Difficult to cache without meta-data.

. Limited client IP addresses - IPV6

Still a ways off. And there's always the private/public address thingy.

. Anonymity - Not always a good thing

Internal opacity usually is a good thing.

. Firewall - Open up connections to/from valid hosts/ports

Access control usually is a good thing.

. Monitoring/filtering - Requirements spec for binary data

Many organisations have a legal requirement to audit their activities. Certainly mine does.

BFN, Mark.

Cheers Richard Maher

"Mark Daniel" <mark.daniel@xxxxxxxxxx> wrote in message
news:011308d4$0$20645$c3e8da3@xxxxxxxxxxxxxxxxxxxx
Richard Maher wrote:
Hi Mark,

(I purchased it when AU$ was almost at US$ parity :-)
Aaah, it seems like only weeks ago :-(
I bought it through Barnes and Noble in late May '08 for US$36.00 plus
US$13.00 P&P, and I think my credit card statement said something like
AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
at US$0.65 now escapes me - perhaps that's one reason I'm still working
for wages.

It was a good 'background' read but not directly applicable to my
daytime duty statement these days. I had not (as I indicated to Roland
I might) gotten around to a public review (that would have required a
second read). Willem Grooters provided one I'd generally endorse.

At around the same time I purchased Heller's, "Catch 22" (shipped to one
of my daughters), Earl's, "Digital Equipment Corporation (MA) (Images
of America)", and Schein's, "DEC Is Dead, Long Live DEC"; all good
reads and all for different reasons. With the exchange rate more like
2:3 I might have to think think more carefully. (The Earl soft-cover is
a particularly easy but also interesting 'read' I'd recommend to all
interested in DEC :-)

Cheers Richard Maher

PS. Just in case you don't subscribe to the WHATWG mailing list, do you
have
any interest in, or opinions on the following: -
No I don't and indirectly I guess I do.

That any network connectivity has some sandboxing doesn't exactly
surprise me. A network conduit (like SSH or HTTP CONNECT) is carte
blanche for whatever the agent wishes to transfer. No constraint would
be considered negligence.

I'm guessing you mention this because the suggestion below that

"that the time could be better spent providing guidelines for
communication via an asynchronous CGI [originally I read GUI :-]
interface."

sounds remarkably like Tier3 :-)

I agree; why would anyone spend time abstracting interfaces if a
monolithic solution is all that is currently required? Of course this
is an entirely fresh (if not novel) discussion point ...

----- Original Message ----- From: "Shannon"
To: "WHAT working group" >
Sent: Tuesday, October 14, 2008 7:22 AM
Subject: [whatwg] WebSocket and proxies


In the process of testing my WebSocket proposal I discovered the
CONNECT
method has a major restriction. Most proxies disable CONNECT to
anything
but port 443.

The following is from "Squid and the Blowfish":
------------------
It is very important that you stop CONNECT type requests to non-SSL
ports. The CONNECT method allows data transfer in any direction at any
time, regardless of the transport protocol used. As a consequence, a
malicious user could telnet(1) to a (very) badly configured proxy,
enter
something like:
... snip example ...
and end up connected to the remote server, as if the connection was
originated by the proxy.
-------------------

I verified that Squid and all public proxies I tried disable CONNECT by
default to non-SSL ports. It's unlikely many internet hosts will have
443 available for WebSockets if they also run a webserver. It could be
done with virtual IPs or dedicated hosts but this imposes complex
requirements and costs over alternatives like CGI.

The availability and capabilities of the OPTIONS and GET protocols also
varied from proxy to proxy. The IETF draft related to TLS
(http://tools.ietf.org/html/draft-ietf-tls-http-upgrade-05) has this to
say:
-------------------
3.2 Mandatory Upgrade

If an unsecured response would be unacceptable, a client MUST send
an OPTIONS request first to complete the switch to TLS/1.0 (if
possible).

OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
-------------------

So according to this draft spec OPTIONS is the only way to do a
*mandatory* upgrade of our connection. Once again this failed in
testing
-------------------
=> OPTIONS * HTTP/1.1
=> Proxy-Connection: keep-alive
=> Connection: Upgrade
=> Upgrade: WebSocket/1.0
=> Host: warriorhut.org:8000
=>
<= HTTP/1.0 400 Bad Request
<= Server: squid/3.0.STABLE8
--------------------

Other proxies gave different errors or simply returned nothing. The
problem may be related to the Upgrade and Connection headers rather
than
OPTIONS, since I had similar issues using Connection: Upgrade with GET.

I had the most success using GET without a Connection: Upgrade header.
It seems that the proxy thinks the header is directed at it so it does
not pass it on to the remote host. In many cases it will abort the
connection. Using the Upgrade: header without Connection allows the
Upgrade header through to the actual websocket service.

It seems to me that whatever we try in many cases the connection will
be
silently dropped by the proxy and the reasons will be unclear due to
the
lack of error handling. There seems to be a wide variation in proxy
behaviour for uncommon operations. I suppose proxy developers could fix
these issues but whether a significant rollout could be achieved before
HTML5 is released is questionable.

Given that an asynchronous connection cannot be cached the only reasons
remaining for going through a proxy are anonymity and firewall
traversal. Automatically bypassing the users proxy configuration to
solve the issues above has the potential to break both of these. It
would be a significant breach of trust for a UA to bypass the users
proxy and some networks only allow connections via a proxy (for
security
and monitoring).

It seems that we're stuck between a rock and hard place here. In light
of this I reiterate my earlier suggestion that the time could be better
spent providing guidelines for communication via an asynchronous CGI
interface. This would allow reuse of existing port 80 and 443 web
services which would resolve the cross-domain issues (the CGI can relay
the actual service via a backend connection) and most of the proxy
issues above (since proxy GET and CONNECT are more reliable on these
ports).
Shannon

"Mark Daniel" <mark.daniel@xxxxxxxxxx> wrote in message
news:01110d0c$0$20616$c3e8da3@xxxxxxxxxxxxxxxxxxxx
yyyc186 wrote:
The Minimum You Need to Know About Service Orieted Architecture by
Roland Hughes

Award-Winner in the Business: Technology/Computers/Internet category
of the National Best Books 2008 Awards, sponsored by USA Book News
Congratulations Roland!

(I purchased it when AU$ was almost at US$ parity :-)

You can find this book in Island Computer's Web store.


.

Relevant Pages

  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... The graphed 'events' are individually and asynchronously provided from the server to the client over a persistent connection and each respective graphical element is equally asynchronously updated. ... However it can emulate asynchronous, raw network streams via a Web Socket server / raw IP network proxy. ... If you mean Web Sockets can't through existing HTTP proxy then the ...
    (comp.os.vms)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... other requests while it's streaming its long-poll (or words to that effect ... If you mean Web Sockets can't through existing HTTP proxy then the ... Orbited is a service used to accept Web-style socket connection ...
    (comp.os.vms)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... originated by the proxy. ... Mandatory Upgrade ... Connection: Upgrade ... I had the most success using GET without a Connection: Upgrade header. ...
    (comp.os.vms)
  • Banana Republic (was Re: OpenVMS Book Wins award)
    ... originated by the proxy. ... Mandatory Upgrade ... Connection: Upgrade ... I had the most success using GET without a Connection: Upgrade header. ...
    (comp.os.vms)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... CONNECT handshake to give me a Tunnel for my Socket over a httpS connection ... originated by the proxy. ... Mandatory Upgrade ... I had the most success using GET without a Connection: Upgrade header. ...
    (comp.os.vms)