Individual XmlHttpRequest requests over HTTPS??

[bizt]

Hi,

I have a page that makes many XmlHttpRequest requests from a single
page. This works fine but I need some requests to be made over a
secure connection. To my understanding, when setting the location of
the path to the file to fetch during the XmlHttpRequest request it has
to the be the path relative to the web page such as /secret.php and
NOT a full URL such as https://www.example.com/secret.php .. is this
about the general idea?? Would I be correct in saying that the only
way I can made secure requests by making the whole page HTTPS?? The
only problem for me with this is that every transfer form the server
(images, non-private data, etc) would have to be over HTTPS which puts
some excess strain at the backend when onl a small portion of data
needs to be protected.

Can anyone make any suggestions that might help me solve this issue?
Thanks

Burnsy

[Henry]

On May 29, 12:03 pm, bizt wrote:

Hi,

I have a page that makes many XmlHttpRequest requests from a
single page. This works fine but I need some requests to be
made over a secure connection. To my understanding, when
setting the location of the path to the file to fetch during
the XmlHttpRequest request it has to the be the path relative
to the web page such as /secret.php and NOT a full URL such
as https://www.example.com/secret.php.. is this about the
general idea??

No, the URL used with XML HTTP request objects may be absolute or
relative.

Would I be correct in saying that the only way I can made
secure requests by making the whole page HTTPS??

Yes, but not any reason related to the form of the URL, but rather
because a page originating from one domain may not make XML HTTP
requests to another domain (and http: and https: domains cannot be the
same domain).

The only problem for me with this is that every transfer
form the server (images, non-private data, etc) would
have to be over HTTPS which puts some excess strain at
the backend when onl a small portion of data needs to be
protected.

Yes, there is an overhead in HTTPS.

Can anyone make any suggestions that might help me solve
this issue?

It is going to be important to encourage the client-side caching of
everything that can be (safely) cached, such as images and JS files.
Over an HTTPS connection the browser is very likely to default to
considering everything it receives as 'private' (and so non-cacheable
(which makes sense if a secure protocol is in use)) unless it receives
HTTP headers that positively assert otherwise.

[Thomas 'PointedEars' Lahn]

Henry wrote:

On May 29, 12:03 pm, bizt wrote:

>I have a page that makes many XmlHttpRequest requests from a
single page. This works fine but I need some requests to be
made over a secure connection. To my understanding, when
setting the location of the path to the file to fetch during
the XmlHttpRequest request it has to the be the path relative
to the web page such as /secret.php and NOT a full URL such
as https://www.example.com/secret.php.. is this about the
general idea??

No, the URL used with XML HTTP request objects may be absolute or
relative.

However, since XHR does not allow accessing another domain from within the
sandbox, the set of reasonable uses of (absolute) URIs (in contrast to
relative URI-references, commonly called "relative URIs") there is rather
limited.

>Would I be correct in saying that the only way I can made
secure requests by making the whole page HTTPS??

Yes, but not any reason related to the form of the URL, but rather
because a page originating from one domain may not make XML HTTP
requests to another domain (and http: and https: domains cannot be the
same domain).

http: and https: domains can be the same domain, of course. However, the
Same Origin Policy considers them to be of different origin even if the
domain is the same, because at least the URI scheme (and so supposedly, here
actually, the transfer protocol) is not.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee