Re: Release date for Privoxy 3.0.20 beta

On 1/4/13, Fabian Keil <[email protected]> wrote:
> Lee <[email protected]> wrote:
>
>> On 1/1/13, Fabian Keil <[email protected]> wrote:
>> > Lee <[email protected]> wrote:
>> >
>> >> On 1/1/13, Fabian Keil <[email protected]> wrote:
>> >> > Lee <[email protected]> wrote:
  [.. snip lots ..]

>> >> It's just a cosmetic issue, but I suspect it's going to confuse people
>> >> with some requests logged as "http://site..." and other requests
>> >> logged as "site:443"
>> >
>> > That's probably true.
>> >
>> > It's a pretty recent change for feature request #3596294 and I don't
>> > feel strongly about it. If we revert it, it should probably be reverted
>> > before the release, though.
>> >
>> > In my opinion adding https:// isn't an option because Privoxy
>> > neither knows that its actually https:// and even if it was,
>> > the path would be missing. It might confuse less people, but would
>> > also be technically wrong.
>>
>> I'd go with technically wrong and less support requests/ user
>> confusion pretty much every time :)
>
> Technically wrong software makes me sad.

Well.. I still feel that way sometimes, but 1) the attitude at my work
is that as long as the users aren't complaining there's nothing wrong
and 2) part of my rating depends on how fast I close support tickets.
I don't get rated on how technically correct the fix is, so I've been
taught to have a strong bias for expediency.

> So far the old correct
> behaviour didn't seem to have a caused a lot of support requests
> and thus should achieve both goals at the same time.

agreed


>> I still see the "client side of the connection got closed" msg
>> occasionally, but it doesn't seem to be causing any problems and every
>> one I've checked has a long time between the last request & the
>> connection being closed - for example:
>>
>> 2013-01-03 21:04:08.500 00000cf8 Request:
>> http://i1.blogs.msdn.com/themes/wireframe/Images/Weblogs/icon-rss.gif
>> 2013-01-03 21:28:37.022 00000cf8 Error: The client side of the
>> connection on socket 1736 got closed without sending a complete
>> request line.
>
> One the one hand it would be interesting to know if the client sent
> any data at all for the request or how long the client connection was
> open, but in general this situation doesn't necessarily imply a bug
> in Privoxy (or the client) so as long as it doesn't affect the user
> experience we can probably ignore it.
>
> I also seem to get a couple of them myself every now and then:
>
> fk@r500 ~/git/privoxy $grep "client side"
> /usr/jails/privoxy-jail/var/log/privoxy/privoxy.log
> 2013-01-02 19:02:55.744 801c09c00 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-02 19:03:14.612 801c07c00 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-02 19:03:33.829 801c08c00 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-02 19:04:22.216 801c07800 Connect: The client side of the connection
> on socket 15 got closed without sending a complete request line.
> 2013-01-03 11:57:25.847 801c09000 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-03 11:57:38.303 801c09800 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-03 11:57:56.839 801c09400 Connect: The client side of the connection
> on socket 7 got closed without sending a complete request line.
> 2013-01-03 13:30:45.639 801c08000 Connect: The client side of the connection
> on socket 9 got closed without sending a complete request line.
> 2013-01-03 13:40:03.948 801c07400 Connect: The client side of the connection
> on socket 6 got closed without sending a complete request line.
> 2013-01-03 22:14:57.384 801c08000 Connect: The client side of the connection
> on socket 3 got closed without sending a complete request line.
>
> It's interesting that the socket number distribution seems to be
> highly uneven, so it might be the result of a some kind of connection
> management done by Firefox.
>
> For example optimistically sending "GET http://" and keeping the
> connection idle until a new request has to be made and the complete
> URL is known could cause this, although this seems like a somewhat
> ridiculous performance optimisation.
>
> I'll try to look into this before the release.

Thanks.  I'm still trying to do my cram course on client/server
programming but it doesn't feel like I'm picking it up all that fast
:(

Lee

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812