Project

General

Profile

Bug #3250

Update to 3.3.3 Causes Links to Add Extra '_=/' in URL

Added by Josh Lampco about 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
06/03/2014
Due date:
% Done:

0%

Estimated time:

Description

After updating to 3.3.3, none of my links will work correctly. I noticed that the URL has an extra _=/ in it.

An example URL reads, http://192.168.220.139/?_=/_=/maps/US instead of http://192.168.220.139/?_=/maps/US as it did before updating.

The only nuance that I notice to this link issue is that if I delete the extra _=/ it never comes back and all of my links work correctly for the duration of the session. I do not have any idea where to even start debugging this issue. Can anyone point me in the right direction?


Files

hello.cpp (1.08 KB) hello.cpp internal-path-example Josh Lampco, 06/05/2014 02:22 AM
wt_config.xml (22.5 KB) wt_config.xml Modified Config File Josh Lampco, 06/10/2014 07:50 PM
#1

Updated by Koen Deforche about 8 years ago

  • Status changed from New to InProgress
#2

Updated by Koen Deforche about 8 years ago

Hey,

I have no idea yet what causes this, but as a workaround, can you avoid the use of these 'ugly' paths? Either specify the static directories when defining the docroot for the wthttpd, or use a deploy path that does not end with a '/' ?

Regards,

koen

#3

Updated by Josh Lampco about 8 years ago

Koen,

Okay, so I specified static directories and now I get URL's like http://192.168.220.139/aps/US?&wtd=randomstring when I should get http://192.168.220.139/aps/US?&wtd=randomstring. I will work on building a test case.

#4

Updated by Josh Lampco about 8 years ago

Oops, I meant that I get URL's like http://192.168.220.139/aps/US?&wtd=randomstring when I should get http://192.168.220.139/maps/US?&wtd=randomstring. It cuts off the first letter for some reason.

#5

Updated by Josh Lampco about 8 years ago

Koen,

Okay, I have modified the "hello" example that is provided with the library. I stripped it down to the bare minimum needed to reproduce the problem. If you run the attached file using the following command line parameters:

--approot=. --docroot=. --http-address=0.0.0.0 --http-port=80

you will see the double "ugly" URL's as I mentioned before. I did what you said and specified static directories to avoid these ugly paths. If you run the attached file using the following command line parameters:

--approot=. --docroot=".;/resources,/favicon.ico" --http-address=0.0.0.0 --http-port=80

you will see that clicking the link will result in the first letter of the internal path being removed ('est-link' instead of 'test-link').

Both of these instances only occur when the deploy-path is root. If I set the deploy-path to be something other than root, the internal paths work correctly.

#6

Updated by Koen Deforche about 8 years ago

  • Status changed from InProgress to Feedback

Hey Josh,

I guess there must also be some relevant settings in wt_config.xml, since this test case works fine for me with either deployment scenarios.

Regards,

koen

#7

Updated by Josh Lampco about 8 years ago

Koen,

First, thank you for taking the time to look into this problem for me.

Secondly, you are correct in assessing that the bug cannot be reproduced using the default settings of the wt_config.xml file. However, I looked at the differences between my config file and the config file that is packaged with the library and found that the bug can be reproduced by simply changing the progressive-bootstrap option to TRUE.

I have attached the config file that is packaged with the wt-3.3.3 library with the progressive-bootstrap option set to TRUE.

Thanks!

#8

Updated by Koen Deforche about 8 years ago

  • Status changed from Feedback to InProgress
  • Target version changed from 3.3.3 to 3.3.4
#9

Updated by Koen Deforche over 7 years ago

  • Status changed from InProgress to Resolved
#10

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF