Description

This is a really minor bug, but it bothers me. When I get wiki notification emails, the URL for the page is always something like https://www.blah.blah:443/wikiname/PageName. The :443 there is totally redundant (and in fact it confuses my browser's memory of http auth details, because it thinks it is talking to two different hosts).

Details

Workaround

The port number comes from the environment variable HTTP_HOST which is read in request.py. I note that the function setHost includes code to ignore the port number if it is one of the standard ports, but in this case setHost is being called with an argument, so that isn't executed.

Here's a suggested fix:

--- request.py.orig     2006-02-23 10:24:43.000000000 +1100
+++ request.py    2006-03-17 11:54:37.000000000 +1100
@@ -352,19 +352,23 @@
     def setHost(self, host=None):
         """ Set http_host

         Create from server name and port if missing. Previous code
         default to localhost.
         """
         if not host:
-            port = ''
+            host = self.server_name + ':' + self.server_port
+
+        # extract the port from the host and remove it, if it's the standard port
+        portpos = host.rfind(':')
+        if portpos != -1:
             standardPort = ('80', '443')[self.is_ssl]
-            if self.server_port != standardPort:
-                port = ':' + self.server_port
-            host = self.server_name + port
+            if host[portpos+1:] == standardPort:
+                host = host[:portpos]
+
         self.http_host = host

     def fixURI(self, env):
         """ Fix problems with script_name and path_info

         Handle the strange charset semantics on Windows and other non
         posix systems. path_info is transformed into the system code

Discussion

Usually HTTP_HOST does not include ":443" - why does it in your case?

Good question. Turns out it is only happening when a page is saved with the external editor action. I'm not sure why that is (I guess it must be something about the way the script makes the HTTP request differently to a normal browser), but in that case env.get('HTTP_HOST') includes the port number. It doesn't look like the code for the ExternalEdit action is doing anything funky on the server side, so I can only guess that under certain circumstances triggered by that script, Apache does include a port number in HTTP_HOST.

OK, so ExternalEdit stuff has to get fixed.

Well, you could see it that way, but I think in this case that ExternalEdit is just acting as an HTTP client to Apache, and whatever it is doing, Apache accepts the request and runs moin.cgi with HTTP_HOST set to "hostname:443" (I have just put some debug in moin.cgi and verified this). So sure, I might be able to fix this in the ExternalEdit client script (which BTW is just using Python's httplib), but I would argue that if ExternalEdit can do it, there's no reason another HTTP client can't either.

• 443 is the ssl port. Why does ExternalEdit do not use the https scheme

  if self.ssl:
  h = HTTPSConnection(self.host)

  Do you have a special configuration of your web server, does it work with the DesktopEdition?

Yep, that's exactly what the code in moinedit.py looks like, and there is no special configuration on the server side. I can't explain why Apache is putting the :443 into the environment just for the ExternalEdit client. I haven't tried the DesktopEdition.

Maybe use ethereal (or tcpdump or ...) to find out what is sent over the wire. And then find out whether it matches the http standard.

Plan

• Priority:

• Assigned to: ExternalEdit developers

• Status: extension bug, not a moin bug

CategoryMoinMoinNoBug