two clients, same version, same server, one sends DAV request and one sends GET

[Joe Chlimoun]

This is driving me nuts...

Both clients are 1.13.1, on the same network going to the same server.  They both are fine when I go directly to the repo, but when I go to to the parent path to get a listing of repos, one client sends HTTP GET to pull the listing, and sends mozilla as user agent, the other uses OPTIONS and Tortoise as user agent (and fails).

Trying like crazy to modify my httpd.conf to accommodate this, but I can't figure out why the clients initiate with different requests.  I took out my redirect for a trailing slash, since that was the original issue with the failing one... even though the good one had no problem with the redirect. Changing between using mod_proxy, mod_rewrite for URL shaping, pass through instead of redirect, etc.

Settings on clients are all defaults, fresh install. The only difference between them is one is Win10 and the other is Win Server 2016 (but no server roles). Win10 is the one that works.

[Stefan]

Are you sure that the one sending OPTIONS does not retry with GET later? Because TSVN first tries to do an 'svn list' and only if that fails it uses the URLDownloadToFile API to get the web page that's served via SVNParentPath.

Because TSVN can't know which is the repo root without trying first. So it always tries the DAV request first and only after that tries the web GET before giving up.

Also, make sure the registry key HKCU\Software\TortoiseSVN\RepoBrowserTrySVNParentPath either does not exist or has a DWORD value of not zero.

[Joe Chlimoun]

Hi Stefan,

Thanks for responding so quickly, and thanks for all your hard work and dedication on this project!

Does it care what response it gets when it sends the first DAV request, or does it fail over to GET on anything other than success?  I've received a range of errors on that client, from complaints about redirect (301/302) for trailing slash, to complaints that the server doesn't support DAV, to now HTTP 500 - internal error.  Been tweaking my httpd.conf for various configurations... the client that works is nearly bulletproof unless I do something really dumb on the server end, but the one that doesn't work never seems to failover to GET. That registry key didn't exist, but I went ahead and created it with a value of 1 just to be explicit, but I assume it's on by default if the key doesn't exist or otherwise can't be read.

So as it stands now, it's failing with HTTP 500 and giving up right away.... It starts with an OPTIONS, gets HTTP 401, then sends OPTIONS with basic auth, then HTTP 500 and it gives us.  When it was getting a redirect for trailing slash, it also gave up and just displayed an error about the redirect.

Thanks,

Joe

[Stefan]

HTTP 500 means "internal server error", which means your server crashed! Try using your web browser on that URL (the one that should serve the repo list) from the machine where the client does not work. If you get a list of repositories with a normal web browser, TSVN should work as well. But not before that works...

As for server setup, you should maybe ask on the svn users list for help with that.

[Joe Chlimoun]

Hi Stefan,

The other client works fine, and a browser works fine from both clients. It's just an error in the DAV config, but it seems that it doesn't matter what the server returns, the client that doesn't work just reports the response and gives up... even on something benign like a redirect.

Thanks,

Joe

[Joe Chlimoun]

Hi Stefan,

Also, this is a production system... I've got several other users on it without issues, even as it returns HTTP 500 to the one client.

Thanks,

Joe

[Joe Chlimoun]

Hi Stefan,

Progress... you were definitely on the right track.  I haven't gotten the broken one to work, but I got the working to break in exactly the same way. When I create that registry key (RepoBrowserTrySVNParentPath) on the good one and set it to 0, it stops failing over to GET and I just get the server response in the repo browser window, whatever that response is (right now it just says the server doesn't support DAV, no more HTTP 500 since I took DAV out of the "/" location). So the behavior is now identical, but intentionally broken on one client and stuck that way on the other.

So I haven't looked at the code, but I presume it defaults to enabling that option (if that's what it's supposed to do when the key doesn't exist). Somehow that isn't functioning on Windows Server 2016 (the only meaningful difference I can figure). Any idea what might interfere with that functionality?

Thanks,

Joe

[Stefan]

Yes, if the registry key does not exists it defaults to true.

But you really, really should check your server logs because a 500 error means that the server crashed, and you really should figure out why.

Another thing: since TSVN uses URLDownloadToFile to get the web page for the SVNParentPath url, you might want to check the security settings on your server.

See here for one possible problem/solution: https://groups.google.com/g/tortoisesvn/c/X0l-ZKgiy3U/m/YLncn-CECAAJ

[Joe Chlimoun]

Hi Stefan,

I do know why I was getting HTTP 500, it isn't a mystery... It was part of my effort to troubleshoot this issue. When sending a DAV request to "/" (not my repo root), I had mod_dav pick it up but I didn't actually configure anything for mod_dav there, so the connection thread would error out and die.  Not a problem, it was just one of my ways of probing at the issue to understand the behavior better (for both the working clients and the non-working one).  I created a handful of "alternate" httpd.conf configurations that worked for the functional client but failed (with different errors) in the non-functional client, so it was a willful action on my part to generate HTTP 500, among others (temp redirect, perm redirect, dav not supported, internal error) - at no point was the server producing these codes unexpectedly, I just wanted to know how the clients reacted... the "good" one succeeded in all configurations, and the "bad" one failed all of them (each time just reporting the error in the repo browser window and giving up, never following up with a GET request).

But I sort of resolved this.

It became clear that that I couldn't troubleshoot further without going through code, so I set up an environment and branched off the tag for 1.13.1... RepositoryBrowser.cpp, TrySVNParentPath(), line 5092, I commented out:

<code>

   if (m_bSparseCheckoutMode)

       return false;

   if (!m_bTrySVNParentPath)

       return false;

</code

I'm not sure why it cares at this point if it's in "sparse checkout mode," since it should only ever try to read it if it got back an error from the server on a DAV request, and the operation is in an initialization anyway.  Might be important if we're checking out immediately from the context menu, I guess, but in my case I'm just trying to load the repo browser to browse, no checkout involved,

No idea why it might be set to sparse checkout mode. I am not doing anything that I'm aware to cause that, at least not anything I'm not doing from the working client. But this workaround did the trick, and I'm not sure exactly what scenario will fail by leaving that commented out... seems like worst case it attempts a GET at the wrong time, but the previous request would have to fail to reach there, so in a practical sense it may not matter.  Nonetheless, it would take someone more familiar with the code and with svn to determine why that logic was put there in the first place. And I basically nullified the setting for TrySVNParentPath... theoretically no different than stock behavior (without reg key overriding it).

Unfortunately, attaching a debugger isn't really possible with my setup. I guess I'm content with my patch, as long as you don't think it will cause some adverse behavior down the line. I suppose I could fill it with trace messages and chase it further that way... I'll see how much I care after some sleep. Long night chasing down environment gremlins. :-)

Actually, completely unrelated, but there was one environment issue I just worked around rather than solve... the msi apparently needs crtmfc\win32\Microsoft.VC142.CRT\vcruntime140_1.dll on the win32 build, but this file doesn't exist. vcruntime140.dll did exist in that folder, and both existed for the x64 version of the path. So I'm not sure how the win32 for 1.13.1 ever created the msi successfully. I guess the file might be living in someone's working copy but never added.

Thanks,

Joe

[Stefan]

On Saturday, August 15, 2020 at 2:00:56 PM UTC+2 Joe Chlimoun wrote:

Hi Stefan,

But I sort of resolved this.

It became clear that that I couldn't troubleshoot further without going through code, so I set up an environment and branched off the tag for 1.13.1... RepositoryBrowser.cpp, TrySVNParentPath(), line 5092, I commented out:

<code>

   if (m_bSparseCheckoutMode)

       return false;

   if (!m_bTrySVNParentPath)

       return false;

</code

I'm not sure why it cares at this point if it's in "sparse checkout mode," since it should only ever try to read it if it got back an error from the server on a DAV request, and the operation is in an initialization anyway.  Might be important if we're checking out immediately from the context menu, I guess, but in my case I'm just trying to load the repo browser to browse, no checkout involved,

sparse checkout mode is only set when the repobrowser is started from the checkout or update dialog.

 

Actually, completely unrelated, but there was one environment issue I just worked around rather than solve... the msi apparently needs crtmfc\win32\Microsoft.VC142.CRT\vcruntime140_1.dll on the win32 build, but this file doesn't exist. vcruntime140.dll did exist in that folder, and both existed for the x64 version of the path. So I'm not sure how the win32 for 1.13.1 ever created the msi successfully. I guess the file might be living in someone's working copy but never added.

the win32 build doesn't need the vcruntime140_1.dll. There's an

<?if $(env.Platform) = 'x64' ?>

<?endif ?>

around that file in the StructureFragment.wxs file.