[jitsi-dev] Bug in HTTP Provisioning


#1

I suspect a bug in Jitsi's HTTP provisioning. I am running Jitsi 2.3.4671.9750 on Mac OS but comparable problems have been encountered by my colleagues running Jitsi on Windows.

In our setup we provide Jitsi configuration data via HTTP provisioning. The resource is secured via HTTPS and HTTP Basic authentication. As multiple users share workstations in our setup, HTTP credentials are not saved but have to be entered at every start of Jitsi.

Jitsi does an HTTP POST request to the provisioning URL on startup, answered by the server with HTTP status 401, upon which a password dialog appears. If the user does not enter his credentials fast enough, the following reproducible error occurs after submission of the password dialog:

org.apache.http.NoHttpResponseException: The target server failed to respond
      at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
      at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
      at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
      at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
      at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
      at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
      at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
      at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
      at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
      at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
      at net.java.sip.communicator.service.httputil.HttpUtils.executeMethod(HttpUtils.java:182)
      at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:507)
      at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:362)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.retrieveConfigurationFile(ProvisioningServiceImpl.java:509)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.start(ProvisioningServiceImpl.java:141)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningActivator.start(ProvisioningActivator.java:147)
      at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
      at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
      at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
      at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
      at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
      at java.lang.Thread.run(Thread.java:680)

The access log on the server does not contain any subsequent request though. My suspicion is that their is a timeout in the HTTP client library. If I am not mistaken, you open the password dialog within your custom implementation of org.apache.http.client.CredentialsProvider and block it until the user is finished entering her credentials. If this takes too long, the client library fails with the aforementioned exception and provisioning fails.

Can you confirm this as a bug?

Thanks in advance,
Gregor

···

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/


#2

Dear Jitsi developers,

should I submit this as an issue to you bug tracker?

Best regards,
Gregor

···

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/

Am 05.06.2013 um 17:53 schrieb Gregor Middell <gregor@middell.net>:

I suspect a bug in Jitsi's HTTP provisioning. I am running Jitsi 2.3.4671.9750 on Mac OS but comparable problems have been encountered by my colleagues running Jitsi on Windows.

In our setup we provide Jitsi configuration data via HTTP provisioning. The resource is secured via HTTPS and HTTP Basic authentication. As multiple users share workstations in our setup, HTTP credentials are not saved but have to be entered at every start of Jitsi.

Jitsi does an HTTP POST request to the provisioning URL on startup, answered by the server with HTTP status 401, upon which a password dialog appears. If the user does not enter his credentials fast enough, the following reproducible error occurs after submission of the password dialog:

org.apache.http.NoHttpResponseException: The target server failed to respond
     at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
     at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
     at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
     at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
     at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
     at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
     at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
     at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
     at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
     at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
     at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
     at net.java.sip.communicator.service.httputil.HttpUtils.executeMethod(HttpUtils.java:182)
     at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:507)
     at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:362)
     at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.retrieveConfigurationFile(ProvisioningServiceImpl.java:509)
     at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.start(ProvisioningServiceImpl.java:141)
     at net.java.sip.communicator.plugin.provisioning.ProvisioningActivator.start(ProvisioningActivator.java:147)
     at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
     at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
     at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
     at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
     at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
     at java.lang.Thread.run(Thread.java:680)

The access log on the server does not contain any subsequent request though. My suspicion is that their is a timeout in the HTTP client library. If I am not mistaken, you open the password dialog within your custom implementation of org.apache.http.client.CredentialsProvider and block it until the user is finished entering her credentials. If this takes too long, the client library fails with the aforementioned exception and provisioning fails.

Can you confirm this as a bug?

Thanks in advance,
Gregor

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hey Gregor,

this one has been fixed and is available in repo and will be available in
nightly build 4680.

Cheers
damencho

···

On Wed, Jun 5, 2013 at 7:53 PM, Gregor Middell <gregor@middell.net> wrote:

I suspect a bug in Jitsi's HTTP provisioning. I am running Jitsi
2.3.4671.9750 on Mac OS but comparable problems have been encountered by my
colleagues running Jitsi on Windows.

In our setup we provide Jitsi configuration data via HTTP provisioning.
The resource is secured via HTTPS and HTTP Basic authentication. As
multiple users share workstations in our setup, HTTP credentials are not
saved but have to be entered at every start of Jitsi.

Jitsi does an HTTP POST request to the provisioning URL on startup,
answered by the server with HTTP status 401, upon which a password dialog
appears. If the user does not enter his credentials fast enough, the
following reproducible error occurs after submission of the password dialog:

org.apache.http.NoHttpResponseException: The target server failed to
respond
      at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
      at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
      at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
      at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
      at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
      at
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
      at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
      at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
      at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
      at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
      at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
      at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
      at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
      at
net.java.sip.communicator.service.httputil.HttpUtils.executeMethod(HttpUtils.java:182)
      at
net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:507)
      at
net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:362)
      at
net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.retrieveConfigurationFile(ProvisioningServiceImpl.java:509)
      at
net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.start(ProvisioningServiceImpl.java:141)
      at
net.java.sip.communicator.plugin.provisioning.ProvisioningActivator.start(ProvisioningActivator.java:147)
      at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
      at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
      at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
      at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
      at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
      at java.lang.Thread.run(Thread.java:680)

The access log on the server does not contain any subsequent request
though. My suspicion is that their is a timeout in the HTTP client library.
If I am not mistaken, you open the password dialog within your custom
implementation of org.apache.http.client.CredentialsProvider and block it
until the user is finished entering her credentials. If this takes too
long, the client library fails with the aforementioned exception and
provisioning fails.

Can you confirm this as a bug?

Thanks in advance,
Gregor

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hey Gregor,

Dear Jitsi developers,

should I submit this as an issue to you bug tracker?

Yes please.

(more below)

Best regards,
Gregor

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/

I suspect a bug in Jitsi's HTTP provisioning. I am running Jitsi 2.3.4671.9750 on Mac OS but comparable problems have been encountered by my colleagues running Jitsi on Windows.

In our setup we provide Jitsi configuration data via HTTP provisioning. The resource is secured via HTTPS and HTTP Basic authentication. As multiple users share workstations in our setup, HTTP credentials are not saved but have to be entered at every start of Jitsi.

Jitsi does an HTTP POST request to the provisioning URL on startup, answered by the server with HTTP status 401, upon which a password dialog appears. If the user does not enter his credentials fast enough,

What do you mean by fast enough? Seconds? Minutes?

the following reproducible error occurs after submission of the password dialog:

org.apache.http.NoHttpResponseException: The target server failed to respond
      at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:95)
      at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:62)
      at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
      at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
      at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
      at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
      at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
      at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
      at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:717)
      at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:522)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
      at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
      at net.java.sip.communicator.service.httputil.HttpUtils.executeMethod(HttpUtils.java:182)
      at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:507)
      at net.java.sip.communicator.service.httputil.HttpUtils.postForm(HttpUtils.java:362)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.retrieveConfigurationFile(ProvisioningServiceImpl.java:509)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningServiceImpl.start(ProvisioningServiceImpl.java:141)
      at net.java.sip.communicator.plugin.provisioning.ProvisioningActivator.start(ProvisioningActivator.java:147)
      at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
      at org.apache.felix.framework.Felix.activateBundle(Felix.java:1904)
      at org.apache.felix.framework.Felix.startBundle(Felix.java:1822)
      at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1192)
      at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
      at java.lang.Thread.run(Thread.java:680)

The access log on the server does not contain any subsequent request though.

Does it normally contain one for the authenticated POST?

My suspicion is that their is a timeout in the HTTP client
library.
If I am not mistaken, you open the password dialog within your custom
implementation of org.apache.http.client.CredentialsProvider and block
it until the user is finished entering her credentials. If this takes
too long, the client library fails with the aforementioned exception and
provisioning fails.

Sounds like this could be the issue. We'd have to check if we can manually re-construct the POST request in order to avoid this (or configure the library with an infinite timeout).

Emil

···

On 10.06.13, 12:28, Gregor Middell wrote:

Am 05.06.2013 um 17:53 schrieb Gregor Middell <gregor@middell.net>:

Can you confirm this as a bug?

Thanks in advance,
Gregor

--
Gregor Middell
e-mail: gregor@middell.net
web: http://gregor.middell.net/

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org