RE: [gupnp] Support for Evented State Variable ?



Title: RE: [gupnp] Support for Evented State Variable ?

Hi,

Thanks for clarifying the issue, looks like this fix accepted.
I'll keep using this fix and in case of encountering a side affect which may broke something I may open another discussion.

Mehmet Sahin

-----Original Message-----
From: Zeeshan Ali (Khattak) [mailto:zeenix gmail com]
Sent: Thu 12/10/2009 5:50 AM
To: gupnp o-hand com
Subject: Re: [gupnp] Support for Evented State Variable ?

Hi again,

On Thu, Dec 10, 2009 at 3:44 PM, Zeeshan Ali (Khattak) <zeenix gmail com> wrote:
>> Let me ask question this way,
>> if I add Close Connection Header to notify_subscriber method of libgupnp, do
>> you think guys it may broke some other things, or it's acceptable ?
>
>  Not that I know of, no! I asked Dan Winship (libsoup maintainer) and
> he said persistent connections are the default when using HTTP/1.1.
> There seems to be no API currently to change the behavior so I guess
> we should:
>
> 1. File a bug against libsoup for addition of such an API.
> 2. Use your solution until the libsoup bug is resolved.

   Seems this behavior is dictated by HTTP specs rather than libsoup
so understandably Dan is not keen on adding any API for this:

----IRC LOG----
<zeenix> danw: someone on gupnp ml is saying that Rygel's
MediaRenderer fails one DLNA test-case unless he sets "Connection:
Close" header on his soup message
<zeenix> so libsoup does persistent connection by default?
<danw> if you're using HTTP/1.1, yes
<zeenix> could there be a prop/api to disable that behavior?
<danw> well, you can connect to request-started on SoupSession and add
"Connection: close" to the message
<danw> you could even write a tiny little SoupSessionFeature that did
that, and then just do soup_session_add_feature_by_type(session,
GUPNP_TYPE_SOUP_CONNECTION_CLOSE_FEATURE)
<danw> to be clear, HTTP/1.1 specifies that connections are persistent
by default. if you don't say "Connection: close", then the connection
MUST be treated as persistent
-------------------

   So I guess we just go for Mehmet's solution unless you find out
other tests failing because of this.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
--
To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]