After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 712183 - about devhelp, wrong URL
about devhelp, wrong URL
Status: RESOLVED FIXED
Product: devhelp
Classification: Applications
Component: General
3.4.x
Other Linux
: Normal minor
: ---
Assigned To: devhelp-maint
devhelp-maint
Depends on:
Blocks:
 
 
Reported: 2013-11-12 21:09 UTC by Jemshid KK
Modified: 2013-11-14 08:52 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
landing page (181.96 KB, image/png)
2013-11-12 21:09 UTC, Jemshid KK 		Details

Description Jemshid KK 2013-11-12 21:09:41 UTC 
Created attachment 259695 [details]
landing page

http://live.gnome.org/devhelp
This is the URL given in devhelp about window.
Which takes me to a page
"This page does not exist yet. You can create a new empty page, or use one of the page templates."
Comment 1 Aleksander Morgado 2013-11-13 07:47:22 UTC 
The correct URL is:
  http://live.gnome.org/Apps/Devhelp

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 2 Christian Persch 2013-11-13 09:59:14 UTC 
Please change http to https.
Comment 3 Aleksander Morgado 2013-11-13 10:03:39 UTC 
(In reply to comment #2)
> Please change http to https.

The HTTP live.gnome.org gets redirected to HTTPS wiki.gnome.org already; isn't that how it should be?
Comment 4 Christian Persch 2013-11-13 14:56:10 UTC 
The initial GET is still to non-https, so the URL is observable. The redirect is only happening by the server's response (302 to the https:// URL). Using https directly avoids this.
Comment 5 Aleksander Morgado 2013-11-14 08:52:20 UTC 
(In reply to comment #4)
> The initial GET is still to non-https, so the URL is observable. The redirect
> is only happening by the server's response (302 to the https:// URL). Using
> https directly avoids this.

Ok, re-fixed. Thanks :)