In the usual deployment scenario, Lightstreamer Server and the Web Server are deployed on different hosts
(or, at least, they are accessed by the clients through different hostnames, as push.mycompany.com and www.mycompany.com)
and the pages coming from the two servers can interoperate thanks to the document.domain setting, which can refer to a common superdomain (as mycompany.com).

Let's suppose, on the other hand, that Lightstreamer Server and the Web Server are deployed on the same host, listening on different ports,
(or, at least, that they are accessed by the clients through the same hostname, as www.mycompany.com).
Note that this is not recommended as a production configuration, because only port 80 (or 443 for https) is ensured to be reached by any client browser.
Nevertheless, the pages from the two servers can still interoperate thanks to the document.domain setting, provided that, as before, you can enlarge it to be a superdomain (as mycompany.com).

In some test environments, you may only have a hostname that doesn't allow a legal superdomain (as localhost) and you may wish to try to have your pages still interoperate.
Or, perhaps, you just don't like to enlarge the domain to mycompany.com when you only need to access a single host: www.mycompany.com.

This is possible, in general, provided that you set document.domain to be the same as the hostname (i.e. www.mycompany.com in our example).
Note that the domain has to be set explicitly: keeping the default domain doesn't work (basically, you could issue something like
document.domain = document.domain;
and, as a side effect, the pages will be allowed to interoperate).

Unfortunately, Internet Explorer prior to version 8 exhibits the opposite behavior,
that is, it lets the pages interoperate if you keep the default domain on all pages, whereas, if some page forces the domain through
document.domain = document.domain;
it will prevent the pages from interoperating.
Because of this browser-dependent behavior, the recommended way of testing when Lightstreamer Server and the Web Server are on the same host and no suitable hostname is available is to assign fake hostnames of the correct format directly on the client machine, by playing on the "hosts" file.

This limitation brings further consequences.
For instance, if the hostname of the Web Server is just mycompany.com (instead of www.mycompany.com) and the hostname of Lightstreamer Server is still push.mycompany.com, then the pages can interoperate in most browsers by setting document.domain as mycompany.com;
on the other hand, there is no setting that can make the pages interoperate on Internet Explorer prior to version 8.
Hence, a similar case is officially not supported by the Web client APIs.

Final note: in Lightstreamer, the domain setting has to be performed through a call to setDomain instead of an explicit assignment to document.domain; in case the default domain has to be kept, calling setDomain(null) should be preferred.