https+jquery problem

[rejetto]

j'ai fait un post à rejetto concernant l'accès au fichier jquery.js quand la personne n'est pas encore identifiée, je suppose que ce sera dans la 274, en tout cas une version allégé de ce fichier existe dans la compilation, et est chargé en cas de défaillance de l'url.
dans le template on trouve déjà
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>
    <script> if (typeof jQuery == "undefined") document.write('<script type="text/javascript" src="/?mode=jquery"></'+'script>'); </script>

your suggestion is not related to this problem.
the browser complains when something is loaded linked via HTTP in an HTTPS page. It wants all to be https.
this problem arises even if the server is public and no login is required.

To save some bandwidth, i suggest to solve it by linking to google but with https instead of http. Their servers are made so to work with https as well.

Let's try to automate this solution.
We face the problem that with stunnel we are proxied, and we cannot detect https usage at HFS level.
At browser level we can, so in javascript it would go for document.location.protocol == "https:" .
But the default template tries to not require javascript for all basic needs, and this appears to be basic.
We can rely on the "https" option we already have in HFS, it seems a coherent solution, even if it is not totally automated..
At the moment HFS doesn't let templates to know the value of this option, so i have to introduce it.
From #274 the default template will feature this line

   <script type="text/javascript" src="{.get|protocolon.}ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.js"></script>

I hope this will solve the problem.

[rejetto]

i just got another idea:
to always link to https://google

pro: no worries
con: it may slow down the loading of the page.

I'm interested in knowing if you have some testing results about this.

[AvvA]

Sorry to reply so lately, not that I'm not following, but I don't receive email notification anymore, if you've got a clue about this I'm interested. I already verified my options with no luck, all seems good...

---
I tested with HTTP HFS' share and HTTPS HFS' share, in both cases it works like it should :
- HTTP loads jquery.js via HTTPS without problem and quite quickly,
- HTTPS display a beautiful solid lock, and users won't ask about a tremendous exclamation mark anymore

Despite the fact the second idea works and is simplest to code (yeah, well... ^^'), the current working protocol would be great too as a variable like you suggest in the first idea. This way, templates can be HTTPS and HTTP at the same time without change, and without navigator warning.

Also, you're talking about saving bandwidth, but the file is loaded only once by session, after that, as there is no change in the file, cache is commonly used, but you're right, for people who pay their bandwidth it should be better to take it from google anyway.


I don't really know the impact on security to make an SSL connexion with an Stunnel-HFS server that send an HTML document asking for a file from another SSL server. The fact is that google is a giant curious spider, and that HFS via Stunnel theoretically wants to be discrete, perhaps I'm a bit excessive, but I still prefer to do like I said in the FAQ topic, and send myself this file to friends via HFS-Stunnel, and doing so I don't give any referrer to google.
But I admit it's perhaps extreme...


By talking about jquery.js, I don't really know which part of it you're using, but perhaps it would be possible to include only functions really used, at the same level as the IE blink. But perhaps it's not legal, and/or perhaps you use a large amount of it.

[rejetto]

AFAIK, the only informations sent to google when requesting jquery is the client's IP, and maybe the referrer (the url of the HFS server) but i'm not sure about the latter, just guessing. Anyway, the security of a server should never rely on its address to be hidden because you get scanned on the net.
cookies are bound to the domain.

there's nothing bad in providing jquery yourself, it's just not the default choice.
it's not just HFS using google's files, it's a common practice to improve general web experience. I found this practice not with HFS but with my job of web designer. You will find more if you search.

Shrinking down jquery would be an heavy work, and would be invalidated by time, as needs change over time.

[AvvA]

I told you it was extreme

Yes indeed, you're right, and I'm not relying on hiding my site address, It's more the fact that the less you provide the more you're "cloaked". (of course you're not, but at least you're perhaps less visible)
FYI, I'm relying with care on 3 things that work together,
- not giving information to anyone that doesn't need it -> i.e. no public page telling it's HFS running,
- using passworded access,
- and of course, like HFS uses HTTP protocol that send clearly user and password, first wrap it thru SSL.

I'm aware that's not perfect (nothing is), but it's a step to privacy.


I understand the "common practice", and agree to say it's useful in some ways, just not all of them.
That's perhaps personal, and reflect my point of view about "the cloud". It's good but it's bad...
Yeah, I'm tortuous ^^' sorry for that...

[psayre23]

Another option is to leave off the protocol when making the call. It is still a valid link. This is a trick Paul Irish coined (one of the jQuery guys). He calls it "Protocol Relative URL" and has exactly the example you are using. http://paulirish.com/2010/the-protocol-relative-url/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>

[AvvA]

That's a nice trick, thank you for sharing it 

[rejetto]

wow
i'm going to use it