Open rju opened 2 weeks ago
author Jan Waller -- Wed, 13 Mar 2013 23:39:39 +0100
Replying to
KIEKER-571
Open
:
> http://kieker.uni-kiel.de/trac/ (trac)
> * http://trac.kieker-monitoring.net/ (correct redirect)
Why isn't http://trac.kieker-monitoring.net/ the main url? Only to get a valid certificate? Only core users have accounts and thus need of ssl encryption ...
author André van Hoorn -- Wed, 13 Mar 2013 23:46:23 +0100
The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
author André van Hoorn -- Wed, 13 Mar 2013 23:47:30 +0100
Replying to
KIEKER-571
Open
:
> * https://kieker-monitoring.atlassian.net/ (should redirect)
yes, this should be fixed.
author Jan Waller -- Thu, 14 Mar 2013 07:36:47 +0100
Replying to [avh|comment:2]:
> The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
But this is only relevant for the https links, not for the http. And https links are only relevant for the core developers with accounts.
author André van Hoorn -- Thu, 14 Mar 2013 08:32:57 +0100
Replying to [jwa|comment:4]:
> Replying to [avh|comment:2]:
> > The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
>
> But this is only relevant for the https links, not for the http. And https links are only relevant for the core developers with accounts.
Sure, but it happens easily that we copy/paste a link to a trac page from the address panel to a web site etc. And then Google will recognize the https links, crawl them, and list them as part of search results. Users click on them and will find the invalid certificate warning. We've seen all this before in our old setting .
author Jan Waller -- Fri, 15 Mar 2013 10:52:40 +0100
Are there further domain redirects not yet listed?
author André van Hoorn -- Fri, 15 Mar 2013 10:54:59 +0100
Replying to [jwa|comment:6]:
> Are there further domain redirects not yet listed?
see KIEKER-966 Done
author Jan Waller -- Fri, 15 Mar 2013 11:14:44 +0100
Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
We should also make sure to always use .kieker-monitoring.net/ in all external links (e.g., on the hp).
author André van Hoorn -- Fri, 15 Mar 2013 11:19:28 +0100
Replying to [jwa|comment:8]:
> Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
Maybe a wiki page with an (updated?) version of the figure [/attachment/ticket/421/urls.png], linking to a monitoring script (based on wget, jmeter, or whatever), testing the domains and redirects. The script would be the most consistent documentation.
>
> We should also make sure to always use .kieker-monitoring.net/ in all external links (e.g., on the hp).
yes, should be fixed if there are wrong ones.
author André van Hoorn -- Fri, 15 Mar 2013 11:31:42 +0100
Replying to [avh|comment:9]:
> Replying to [jwa|comment:8]:
> > Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
>
> Maybe a wiki page with an (updated?) version of the figure [/attachment/ticket/421/urls.png], linking to a monitoring
SVG source for the image available in the resources Git (/web/urls/)
author Jan Waller -- Fri, 15 Mar 2013 14:24:00 +0100
Things to do:
* http://kieker-monitoring.org, http://kieker-monitoring.com, and http://kieker-monitoring.de should redirect instead of alias (same for https, which currently just redirect to each http variant).
Update and add to the page [domains]
author André van Hoorn -- Tue, 14 May 2013 15:39:18 +0200
Replying to [jwa|comment:11]:
> Things to do:
> * http://kieker-monitoring.org, http://kieker-monitoring.com, and http://kieker-monitoring.de should redirect instead of alias (same for https, which currently just redirect to each http variant).
> * http://git.kieker-monitoring.net/ (so no valid repo) should provide 404 instead of "Hi"
From KIEK-982:
It would make sense to add a redirect to http://trac.kieker-monitoring.net/wiki/VCSRepositories/, e.g., using plain HTML:
<html> <head> <meta http-equiv="refresh" content="0; url=http://trac.kieker-monitoring.net/wiki/VCSRepositories/"> </head> <body> </body> </html>
> * http(s)://build.se.informatik.uni-kiel.de/kieker/trac/* should redirect to http(s)://kieker.uni-kiel.de/trac/*
>
> Update and add to the page [domains]
> * alternate git domains?
> * http://git.kieker-monitoring.* (with * =/= net) does not work
JIRA Issue: https://kieker-monitoring.atlassian.net/browse/KIEKER-571 Original Reporter: Jan Waller (JIRA username)
Currently our pages are reachable under several separate domains:
[domains]
Checklist:
JIRA Comments:
557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Wed, 13 Mar 2013 23:39:39
Replying to KIEKER-571 Open :
> http://kieker.uni-kiel.de/trac/ (trac)
> * http://trac.kieker-monitoring.net/ (correct redirect)
Why isn't http://trac.kieker-monitoring.net/ the main url? Only to get a valid certificate? Only core users have accounts and thus need of ssl encryption ...
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Wed, 13 Mar 2013 23:46:23
The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Wed, 13 Mar 2013 23:47:30
Replying to KIEKER-571 Open :
> * https://kieker-monitoring.atlassian.net/ (should redirect)
yes, this should be fixed.
557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Thu, 14 Mar 2013 07:36:47
Replying to [avh|comment:2]:
> The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
But this is only relevant for the https links, not for the http. And https links are only relevant for the core developers with accounts.
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Thu, 14 Mar 2013 08:32:57
Replying to [jwa|comment:4]:
> Replying to [avh|comment:2]:
> > The main reason we introduced http://kieker.uni-kiel.de (plus subdomains) was that this is where we get a valid SSL certificate for. Once we use the invalid SSL certificates for (e.g.) http://trac.kieker-monitoring.net/, this may show up in Google's results list and external user clicking on the search results receive an invalid certificate warning.
>
> But this is only relevant for the https links, not for the http. And https links are only relevant for the core developers with accounts.
Sure, but it happens easily that we copy/paste a link to a trac page from the address panel to a web site etc. And then Google will recognize the https links, crawl them, and list them as part of search results. Users click on them and will find the invalid certificate warning. We've seen all this before in our old setting .
557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 10:52:40
Are there further domain redirects not yet listed?
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 10:54:59
Replying to [jwa|comment:6]:
> Are there further domain redirects not yet listed?
see KIEKER-966 Done
557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 11:14:44
Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
We should also make sure to always use .kieker-monitoring.net/ in all external links (e.g., on the hp).
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 11:19:28
Replying to [jwa|comment:8]:
> Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
Maybe a wiki page with an (updated?) version of the figure [/attachment/ticket/421/urls.png], linking to a monitoring script (based on wget, jmeter, or whatever), testing the domains and redirects. The script would be the most consistent documentation.
>
> We should also make sure to always use .kieker-monitoring.net/ in all external links (e.g., on the hp).
yes, should be fixed if there are wrong ones.
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 11:31:42
Replying to [avh|comment:9]:
> Replying to [jwa|comment:8]:
> > Maybe we can create a wiki page with all domains and redirects and make sure they are working correctly (redirect instead of alias).
>
> Maybe a wiki page with an (updated?) version of the figure [/attachment/ticket/421/urls.png], linking to a monitoring
SVG source for the image available in the resources Git (/web/urls/)
557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 14:24:00
Things to do:
* http://kieker-monitoring.org, http://kieker-monitoring.com, and http://kieker-monitoring.de should redirect instead of alias (same for https, which currently just redirect to each http variant).
Update and add to the page [domains]
557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Tue, 14 May 2013 15:39:18
Replying to [jwa|comment:11]:
> Things to do:
> * http://kieker-monitoring.org, http://kieker-monitoring.com, and http://kieker-monitoring.de should redirect instead of alias (same for https, which currently just redirect to each http variant).
> * http://git.kieker-monitoring.net/ (so no valid repo) should provide 404 instead of "Hi"
From KIEK-982:
It would make sense to add a redirect to http://trac.kieker-monitoring.net/wiki/VCSRepositories/, e.g., using plain HTML:
> * http(s)://build.se.informatik.uni-kiel.de/kieker/trac/* should redirect to http(s)://kieker.uni-kiel.de/trac/*
>
> Update and add to the page [domains]
> * alternate git domains?
> * http://git.kieker-monitoring.* (with * =/= net) does not work