Should CSS vary by protocol (HTTP vs HTTPS)?

Question

I have developed a site using the usual suspects: MVC & jQuery. The production site is SSL...but I also have a backdoor to test it over http as well.

The overall structure of the page is:

<body>
  <div class="container">
    <div class="nav"/>
    <div class="control"/>
  </div>
</body>

...and the related .css looks like this:

.container { height: 100%; width: 100%; }
.nav { float: left; width: 23%; overflow-y: auto; overflow-x: hidden; }
.control { float: right; width: 74%; }

When I look at it via http, the nav's content is too large and it's vertical scrollbar shows up. However, when I look at it through the https address, the .nav runs down the page, and the whole page has a scrollbar.

I would prefer to have the behavior in the http view.

If I add:

html, body { height: 100%; width: 100%; }

...it has no net effect in http...however, it acts like I had overflow-y: hidden on the html and/or body.

The variance in behavior is consistent across at least these browsers: ie8, ie9 and chrome.

Is there anything I can do to keep the http behavior in https? Is the difference in behaviors documented anywhere?

I've posted images of the page, as seen through the http and the https binding on the same site:

flickr.com/photos/92527792@N04/8409094719/in/photostream flickr.com/photos/92527792@N04/8410189866/in/photostream

Just to be clear, there appears to be no problem whatsoever in loading the files into the browser. The .css, .js, and html are all coming down fine. The difference appears to be in how the browser handles the content once it comes down, treating the html that comes through port 443 just a bit differently than html that comes through 80.

Thanks for your time,

Clay

There should be no difference. Make sure the files you are using/viewing are exactly the same. Have you looked at the server access logs for errors? Open your browser developer interface and see if you have any 404 errors. If the codes are 404, then I would look into the httpd.conf file (assuming you are using Apache) to see what the DocumentRoot is for your port 443 directives. — Oliver Tappin
– Oliver Tappin, Commented Jan 24, 2013 at 0:46
Try and open up firebug and look at the net tab. Do you see any differences (like broken links or references) when you switch protocols? — Jason Sperske
– Jason Sperske, Commented Jan 24, 2013 at 0:48
Be sure to clear your browser cache, different protocol will mean that there will be different caches for the same files. — zzzzBov
– zzzzBov, Commented Jan 24, 2013 at 0:52
No errors in the browser console from either view. I agree there should be no differences. — Clay
– Clay, Commented Jan 24, 2013 at 0:54
Should have mentioned this...we're sending No Cache headers as this is an application with content that varies quickly over time. Also, while testing, I'm sending the css with a ? followed by the time. — Clay
– Clay, Commented Jan 24, 2013 at 0:58

Patashu · Accepted Answer · 2013-01-24 00:48:10Z

1

http:// and https:// are not file formats nor do they alter the file in anyway, they indicate the protocol the file will be transferred over e.g. file:// and ftp:// pointing to the same file would also transfer identical data.

Make sure that the same .css file is being used in both cases.

answered Jan 24, 2013 at 0:48

Patashu

21.8k4 gold badges49 silver badges53 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Clay Over a year ago

I understand. I'm actually looking at the same page through different bindings...not different pages. I'm somehow seeing that the browser is acting differently depending on which address I go through. This is the first time I've ever seen such differences. There are no 40x errors. Mystery

OmegaJunior · Accepted Answer · 2013-01-24 04:48:04Z

0

Clay,

Make sure the page is requesting its .css file with a protocol-relative uri. (Assumption: the offending css exists in a separate file insteD of inside the page itself.)

Otherwise, you get non-secured pages requesting secured content and vice-versa, which will lead to loading problems under certain security settings. (Some browsers simply deny access, others warn first, and some offer user preferences about this behaviour.)

A protocol-relative uri is created by removing the protocol from the original url. For instance:
If the original url reads https://sub.domain.com/folder/my.css
its protocol-relative counterpart reads: //sub.domain.com/folder/my.css

answered Jan 24, 2013 at 4:48

OmegaJunior

463 bronze badges

1 Comment

Clay Over a year ago

Thanks - MVC, if you follow the idioms it provides, ensures that your links are protocol-less, app-root-relative. I checked just to be sure ;-)

Collectives™ on Stack Overflow

Should CSS vary by protocol (HTTP vs HTTPS)?

2 Answers 2

1 Comment

1 Comment

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

1 Comment

Your Answer

Sign up or log in

Post as a guest

Related