As illustrations, here are the status of our SSL reports
https://www.ssllabs.com/ssltest/analyze.html?d=openmandriva.org
and our smtp report
http://www.mail-tester.com/web-oQMAjs
It doesn't seems like this, but each step requires a lot of work :)
For global website speed, we're not bad (this is the result without CDN)
http://gtmetrix.com/reports/blog.openmandriva.org/fnvN9UU0
The result with CDN gave us a double A, however there are still
optimizations to do, and we want to avoid going totally through the CDN
(because we don't want an intermediary between our websites and the
users) but just delegate the assets.
On 15/04/2015 22:49, Raphaël Jadot wrote:
On 15/04/2015 21:28, Kate Lebedeff wrote:
Hi Raph
Many people who know how to do this have this problem:)
And at the same time our sites are the only ones which show problem:(
Probably there is something on the other end?
would be frustrating if our users would be bumping into such a thing..
Thank you
Just to make a quick reply, we had monitored for for few days the use
of a CDN (http://en.wikipedia.org/wiki/Content_delivery_network )for
propagating contents of our website in several Points of Presence
around the world, for having a faster access for people really far
from France.
After this test, some things are convincing, other not, so we need
make some improvements, so we have bypassed the CDN to go back
directly to our server, and are currently working on pagespeed module.
After this the goal is to keep the connection in the website in
France, but to propagate assets only (images, scripts etc) over CDN.
The CDN let some cookies on the user hard drive, which stays in local
cache for few hours. These cookies are only compatible with the CDN,
not understandable by original server, which results in this error
message. We could have avoid it by forcing all cookies to be
deleted... We were also surprised, next time we'll do.
All this will be explained in a blog post later, but the overall
performance of our website has been greatly improved (not only
website, but also certificate, email service etc.).
For project, unfortunately I can't tell what is the problem, because
it's not a product I manage, however, it may be possible that there is
a dependency break.
For now, I hope Robert will quickly have time to have a look at it,
and for more security in the future, I suggested to put project in a
separated container.
On 15Apr, 2015, at 8:37 PM, Raphaël Jadot wrote:
Hi,
for project, Robert is aware.
About cookie, I guess a cookie refresh is needed, do you know how to
do this?
On 15/04/2015 13:45, Kate Lebedeff wrote:
Hey guys and gals
We have an issue
When I try accessing any of our sites (main, blog, project) I get
following:
400 Bad Request
Request Header Or Cookie Too Large
nginx/1.6.3
Just checked - it is not only me, random check shows that all whom
I ask, have same
We have a problem?
thanks
Kate
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
