Outlook 2013 is not publishing calendar to webdav using settings successful with Outlook 2010

Question

I am successfully publishing availability data (an ics file) to a webdav server, using Outlook 2010. The format of the URL is https://[domain]/public_html/calendar/
When I use the same URL in Outlook 2013, it returns the message "Contacting web server" and then "The upload to 'Calendar' failed. Failed to sign in."
Of course, there's no sign in dialog box provided. So, I change the URL to the format https://[login name]:[password]@URL/public_html/calendar/
There is no "Contacting web server". Instead, Outlook goes directly to the error message "The upload of 'Calendar' failed. The calendar was not published because the connection to the server failed. Make sure your computer has a network connection
and that you typed the correct Web address."
There's nothing wrong with the connection; I've tried this and its failed many times. So, I conclude that Outlook 2013 doesn't like a web address that includes the login credentials.
What changed with Outlook 2013 that prevents it from publishing to the same location successfully published to, by Outlook 2010?

Answer 1

This problem continues, and it's a showstopper.  Honestly, this is so easy to reproduce and so fundamental that I'm surprised that Microsoft hasn't done anything with it.  Tony Chen, your answer isn't really an answer
at all.  Why mark it as an answer? 
Here are the specifics.  I have Microsoft Outlook 2013 (15.0.4667.1000) MSO (15.0.4667.1001) 32 bit (part of Microsoft Office Professional Plus 2013).
In my calendar, I select "Publish Online > Publish to WebDAV Server".  I then have a dialog box that requires that I enter the publishing location URL.
I enter a URL (which is my company's internal WebDAV server URL), in the same form as the example given:
    https://mycompany.com/calendars/
and then I click "Advanced".  I select "Automatic Uploads: Upload updates periodically", with the Update Frequency checkbox checked (to select the server's recommended settings).  I click "OK", and my calendar is published
periodically to the WebDAV server, as expected.
If I monitor traffic with fiddler, I can see that outlook periodically does a PROPFIND and then PUT of my ical data to https://mycompany.com/calendars/myfile.ics.
Next, suppose I want to change the publish settings in some way.  So in my calendar, I select "Publish Online > Change Publishing Options".
Now, the "Location" text box has the previous URL I entered,
plus the name of my .ics file.  So it looks like this in the text box:
    https://mycompany.com/calendars/myfile.ics
I click "OK", and I get an error popup that says "The address you typed is not valid.  Check the address, and try again."  Note that I didn't type the address at all - it is what outlook put there for me.
As a side note:  in Outlook 2010 the URL shown is the same (i.e., the URL includes the .ics file) but the text box is inactive (greyed out) and the "OK" button does not produce this error message).
So, already something has gone very wrong.  In order to try to work around this, I then edit the text box to remove the .ics file (i.e., to put the URL back to what I originally typed,
https://mycompany.com/calendars/).  But now, one of two things will happen, neither of which is ok.
In some cases, Outlook will continue to publish periodically, but when it does, it will do a PUT to
https://mycompany.com/calendars/ - without the myfile.ics suffix.  Naturally, this fails, because the server doesn't know what .ics file it's supposed to put the PUT payload into.
In other cases, Outlook ceases publishing altogether.  It will do a PROPFIND to the URL, but then no PUT.  I have not yet figured out the circumstances of these two failure modes, so I'm not yet sure why one happens and not the other.  But
they are both wrong.
So, the long and short of this is, you cannot change publishing options in Outlook 2013, because the functionality (which worked fine in Outlook 2010) is just plain broken.  I have given the steps required to reproduce this problem, and it seems like
it would be easy to address.  Yet it has been sitting for 1.5 years with no fix.  What will it take to get this fixed?  Microsoft people, please advise - if I can get it fixed by opening a support case then please say so; paying is not an obstacle.