Bug 1322766

Problem is not reproducible with all secure webdav shares. 
Configured local secure webdav server on rhel and not able to reproduce issue while using it.
Problem is reproducible with customer's share hosted on cloudforge.com
Could be related to some server side timeout configuration?

Problem is observed only with few seconds of delay while providing password. 
Problem not observed if password is submitted immediately. 
Can be easily reproducible in case of complex password which may take some time for typing in.
Workaround:
echo password | gvfs-mount davs://user.server/share

Problem command times out after approximately 10 mins with below message..

Error mounting location: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

gvfs debugs logs shows below : 

(process:3099): libsoup-CRITICAL **: soup_session_get_connection: assertion `soup_connection_get_state (item->conn) != SOUP_CONNECTION_DISCONNECTED' failed

After applying patch, gvfs-mount command terminates quickly with below message  if there is delay in providing password

Error mounting location: HTTP Error: Connection terminated unexpectedly

Thanks for a bug report. I can backport he page you gave the link to, but I'm wondering whether it'll help in reality. I mean, you are still not able to connect there when it takes time to enter the password, you are "only" notified earlier. Does it mean that the gvfs code should by patched too, to not ask in SoupSession::authenticate for the password, but rather out of it, sort of asynchronously?

I was not able to reproduce the problem behaviour with my local webdav server. Hence I thought there could be some server side timeout configuration behind this and the bug is just the session getting hang instead of terminating with appropriate error.

It would be better if can get this fixed to have the connection established instead of terminating session with error.

(In reply to Ashish Shah from comment #7)
> It would be better if can get this fixed to have the connection established
> instead of terminating session with error.

Yes, I agree, I only think the current idea is to have this done on the client side, rather than on the libsoup side (which the proposed patch doesn't do anyway), even it would make more sense to have been done on the libsoup, thus each client could benefit.

Comment on attachment 1142137 [details]
Patch based on upstream fix

The upstream bug (https://bugzilla.gnome.org/show_bug.cgi?id=651146) resulted in 3 commits:

  5299595 redirect-test: add a test for accidental connection sharing
  d810888 SoupSession: set the connection to IDLE on unqueuing SoupMessages
  5cb2209 SoupSession: make pause/unpause work in any state

This patch includes all three, but only the middle one is actually needed to fix the bug. Most of this patch is from 5cb2209, but that was only needed to make it possible to write the test case for the bug. (Well, and we wanted it for other reasons too, but reasons not relevant to fixing this bug.)

(In reply to Ashish Shah from comment #7)
> It would be better if can get this fixed to have the connection established
> instead of terminating session with error.

The bug that the patch fixes is that libsoup was killing its own connections in certain cases. If the connection is still getting closed with the patch, then that would appear to be because the server itself is closing it. (Is it still closing it "quickly"? Or when you tested did you wait an extremely long time just for testing purposes?)

The problem reproducer is provide small delay (5 secs or so) to issue password while connecting to customer's share.

without this patch I had to wait quite long (~10 mins) for connection to timeout
As per strace, looks it was polling on dbus socket and then timed out.

With the patched version of libsoup, connection gets terminated immediately. I have not captured the trace with patched version of package. Will do that and update the status here. Also will capture tcpdump and try to look in it to see if it provides clue about the termination from server side or client end.

I should be able to get access to the reproducer by Tuesday.

Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com