Location: problem with bad original URL, identified in bug report #1029478

CHANGES

@@ -6,6 +6,16 @@
 
                                   Changelog
 
+Daniel (16 September 2004)
+- Anonymous filed bug report #1029478 which identified a bug when you 1) used
+  a URL without properly seperating the host name and the parameters with a
+  slash. 2) the URL had parameters to the right of a ? that contains a slash
+  3) curl was told to follow Location:s 4) the request got a response that
+  contained a Location: to redirect to "/dir". curl then appended the new path
+  on the wrong position of the original URL.
+
+  Test case 187 was added to verify that this was fixed properly.
+
 Daniel (11 September 2004)
 - Added parsedate.[ch] that contains a rewrite of the date parser currently
   provided by getdate.y. The new one is MUCH smaller and will allow us to run

lib/transfer.c

@@ -1801,8 +1801,15 @@ CURLcode Curl_follow(struct SessionHandle *data,
       /* We got a new absolute path for this server, cut off from the
          first slash */
       pathsep = strchr(protsep, '/');
-      if(pathsep)
+      if(pathsep) {
+        /* When people use badly formatted URLs, such as
+           "http://www.url.com?dir=/home/daniel" we must not use the first
+           slash, if there's a ?-letter before it! */
+        char *sep = strchr(protsep, '?');
+        if(sep && (sep < pathsep))
+          pathsep = sep;
         *pathsep=0;
+      }
       else {
         /* There was no slash. Now, since we might be operating on a badly
            formatted URL, such as "http://www.url.com?id=2380" which doesn't

tests/data/Makefile.am

@@ -26,7 +26,7 @@ EXTRA_DIST = test1 test108 test117 test127 test20 test27 test34 test46	\
  test512 test165 test166 test167 test168 test169 test170 test171	\
  test172 test204 test205 test173 test174 test175 test176 test177	\
  test513 test514 test178 test179 test180 test181 test182 test183	\
- test184 test185 test186
+ test184 test185 test186 test187
 
 # The following tests have been removed from the dist since they no longer
 # work. We need to fix the test suite's FTPS server first, then bring them

tests/data/test187

@@ -0,0 +1,67 @@
+# Server-side
+<reply>
+<data>
+HTTP/1.1 301 This is a weirdo text message
+Date: Thu, 09 Nov 2010 14:49:00 GMT
+Server: test-server/fake
+Location: /root/1870002.txt?coolsite=yes
+Connection: close
+
+This server reply is for testing a simple Location: following
+
+</data>
+<data2>
+HTTP/1.1 200 Followed here fine swsclose
+Date: Thu, 09 Nov 2010 14:49:00 GMT
+Server: test-server/fake
+
+If this is received, the location following worked
+
+</data2>
+<datacheck>
+HTTP/1.1 301 This is a weirdo text message
+Date: Thu, 09 Nov 2010 14:49:00 GMT
+Server: test-server/fake
+Location: /root/1870002.txt?coolsite=yes
+Connection: close
+
+HTTP/1.1 200 Followed here fine swsclose
+Date: Thu, 09 Nov 2010 14:49:00 GMT
+Server: test-server/fake
+
+If this is received, the location following worked
+
+</datacheck>
+</reply>
+
+# Client-side
+<client>
+<server>
+http
+</server>
+ <name>
+HTTP redirect with bad host name separation and slash in parameters
+ </name>
+ <command>
+http://%HOSTIP:%HTTPPORT?oh=what-weird=test/187 -L
+</command>
+</test>
+
+# Verify data after the test has been "shot"
+<verify>
+<strip>
+^User-Agent:.*
+</strip>
+<protocol>
+GET /?oh=what-weird=test/187 HTTP/1.1
+Host: 127.0.0.1:%HTTPPORT
+Pragma: no-cache
+Accept: */*
+
+GET /root/1870002.txt?coolsite=yes HTTP/1.1
+Host: 127.0.0.1:%HTTPPORT
+Pragma: no-cache
+Accept: */*
+
+</protocol>
+</verify>