6.07 Broke The Http Tunnel Feature

We are aware of one more such situation with IIS version 6 and Windows 2003 (IIS version 5 and XP is not affected).

We believe it is an issue with the IIS/PHP interface and not SQLyog. More precisely the issue is that the web server is not accepting the header:

“Content-Type: application/x-www-form-urlencoded” from external sources. You can test this from a *nix shell (You need *nix to execute POST, but Putty will do):

$ POST [url=”http://serverURL/path_to/SQLyogTunnel.php”]http://serverURL/path_to/SQLyogTunnel.php[/url]

Please enter content (application/x-www-form-urlencoded) to be POSTed:

name=peter&

roll=123&

If you get:

500, timeout error message.

“

.. this is the problem

If it is OK you will get something like:

4not well-formed (invalid token)

Solution:

PHP for windows is available in two builds:

1) a package with an automatic installer

2) a package for manual configuration

This issue has only been seen when 1) was used. Uninstalling and using 2) instead has solved the issue.

You may use this configuration guide:

http://ourthinktank.org/?p=34

BTW: from what version did you upgrade?

Hi,

I am having a similar problem with HTTP Tunneling it used to work fine before version 6 now it just wont connect using this method. I performed the

test as described above and got the following response from SQLyogTunnel.php script but I used fiddler to build the request.

I am using shared hosting(windows) so not much access to server other than web interface their support have been of no help. It is just strange

that it doesnt work all of a sudden… is their an easy way to troubleshoot the HTTP Tunneling?

Regards

Gareth

@Gareth

“It is just strange

that it doesnt work all of a sudden…”

Also you should tell from what version you upgraded!

For you it seems to be another issue. We will need remote access to your server if we shall work with it.

You can:

* create an empty database and a new user that have all privileges (except DROP and GRANT) to that database only (this will ensure that we cannot access your data, what we basically do not want to do!)

* create a ticket to inform about connection details-

Hi,

Thanks for the reply, I was originally using a trial version of 5 and recently bought full version. I have created

a database as requested and will submit the details via issue tracker.

Thanks.

Got your details ..

we will see what we can find out tomorrow!

You can try this binary

http://www.webyog.com/downloads/betas/not_…rlencodeEnt.exe

(special build not using urlencode in the HTTP header – don't forget to replace the tunneller)

Please tell if it solves the issue for you!

We started using urlencode to solve an issue with a specific server configuration (I think it was on some BSD system, but not sure). Now this seems to cause other problems on Windows 2003/IIS version 6.

We plan to make the use of this header optional (if we do not get a better solution!)

Dear,

I have the version 4.14 and I have the same problem.

Was this already resolved? Am I have the option to disable the “urlencode”?

An issue with version 4.14 is definitely not 'url_encode' related.

Can you connect to the tunneller from a browser?

Can you connect to other php scripts in the same folder?

I tried with this 6.07 “special build not using urlencode” release and works greats.

With the 6.14 still having the same error:

“Error No. 1

HTTP Error. Could not connect to the tunneling URL.”

I can use the 6.07 not url_encode but I wold like to use the 6.14 version 😀

If doesn't is the url_encode what can be?

Thanks

We will either

* provide a 6.14 or 6.15beta/RC in both versions

* or find a better ('smart') solution …

in short time. I think in less than 48 hours.

Peter,

Thanks for your attention, and sorry for my mistake, when I write 4.14 I mean the 6.14 version 😛

Thank you again…

I should have realized!

There never was a 4.14! There was a 4.1 and some 4.2 betas were released, but were finally released as 5.0!

HI

The below are the links for downloading 6.15(not released) which does not use “urlencode”.

links

For Trial version

http://www.webyog.com/downloads/betas/not_…odeEntTrial.exe

For Enterprise Version

http://www.webyog.com/downloads/betas/not_…rlencodeEnt.exe

Thanks

Mahesh

Just let me add that this add a single fix to 6.14 (in structure sync)

Thanks… It's works great. 😀

I am having a similar problem using 6.14

I think the problem is with the hosting company, as I can connect to other hosts ok

I just wondered if anyone else has had a similar problem and found a resolution, as the hosting company seem to be scratching their heads.

The problem only happened around a week ago, the same time I upgraded to 6.14, although I don't think this is the fault.

When I try to connect to any of my databases I get the following message returned to me.

“

HTTP/1.1 406 Not Acceptable

Date: Wed, 05 Dec 2007 09:23:19 GMT

Server: Apache/1.3.37 (Unix) mod_jk/1.2.14 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a

X-Powered-By: PHP/4.4.7

Keep-Alive: timeout=15, max=99

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: text/html

“

Thank you in advance

Mark

Did you try the special build that does not use 'urlencode' linked to above?

(note that you will need to use the tunneller shipped with that!)

My hosting company has now managed to solve the problem.

I have included their resolution below, in the hope it may help other people.

“One of the variables in SQLyogTunnel.php was hitting the name_length limit in our security module. I have tweaked it to allow ridiculously long variable names. Please try it now.”

I didn't ask what variable it was.

Regards

Mark

“ridiculously long variable names”

Could you please download the ('tweaked') tunneller, zip and attach here and we will find out what they were!

Or was it the security module and not the tunneller that was 'tweaked' ?

Maybe variables like '$___mysqli_obj', '$___mysqli_tmp' were the problem?

If you can help to get details about this, we would appreciate!

But also your ISP may have done some silly (configuration) mistake and prefer to blame such variable names instead of just admitting that?

My host has sent me the following information

“Dec 5 04:23:19 “server name”: ALERT – configured request variable name length limit exceeded – dropped variable 'localhost“my username”“My password”3306

thanks!

we can of course easily list the variables and sort those after length.

@Julian .. you have a PM