After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 635553 - [neonhttpsrc] authentication support
[neonhttpsrc] authentication support
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.20
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-22 20:21 UTC by Nicola
Modified: 2013-07-17 08:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2010-11-22 20:21:25 UTC
neonhttpsrc doesn't work with url that require authentication for example http://user:pass@1.1.1.2:8080/ works fine with souphttpsrc but not neonhttpsrc
Comment 1 Sebastian Dröge (slomo) 2010-12-18 13:43:10 UTC
Are you planning to work on this?
Comment 2 Nicola 2010-12-18 18:59:26 UTC
seems not so difficult, just add two property and if they are populated follow neon docs:

http://www.webdav.org/neon/doc/html/refauth.html

I can try to make a patch but I have no spare time in the near future,

Nicola
Comment 3 Edward Hervey 2013-07-17 06:27:22 UTC
Is neonhttpsrc still around in 1.x ?
Comment 4 Sebastian Dröge (slomo) 2013-07-17 08:01:34 UTC
Yes, it is even ported to 1.0 it seems. Question is, if this is still needed and if someone is going to work on it?
Comment 5 Nicola 2013-07-17 08:11:47 UTC
souphttpsrc is more complete and more supported I think the efforts should be to improve souphttpsrc (for example it does not support client certificate authentication)
Comment 6 Tim-Philipp Müller 2013-07-17 08:14:30 UTC
> Is neonhttpsrc still around in 1.x ?

I'm quite sure you could have easily figured that one out yourself :P


> Yes, it is even ported to 1.0 it seems. Question is, if this is still needed
> and if someone is going to work on it?

Seeing that someone just ported it, it would appear so, wouldn't it? The reason
for keeping it around is that people (esp. on embedded systems) seem to be
quite picky about their http client libs for some reason. So we'll probably add
a curl client too sooner or later ;)

Having said that, I don't see the need to keep this bug open if no one is working on it.