Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#556 Show full clickable URL + method in MS-Win console

pending
Fabian Keil
5
2012-12-16
2012-12-15
Martin Olsson
No

Concerning the MS console window...

1)
Currently, debug level 1 show lines like this:
2012-12-15 16:50:41.422 00000d40 Request: www.foo.se/bar/spacer

...while debug level 1024 display:
2012-12-15 16:50:41.422 00000d40 Crunch: Blocked: http://www.foo.se/bar/spacer

I would like both URLs to be displayed in a consistent way, i.e. add "http://" to the debug 1 message:
2012-12-15 16:50:41.422 00000d40 Request: http://www.foo.se/bar/spacer
2012-12-15 16:50:41.422 00000d40 Crunch: Blocked: http://www.foo.se/bar/spacer

2)
Currently, debug level 1024 show blocked URLs in blue, while level 1 does not.
I would like both URLs to be displayed in a consistent way, i.e. make URLs in debug 1 messages blue as well.

3)
Now that all URLs are shown in a consistent way, please also make all blue URLs clickable.
Any URL shown in the console should be clickable so one can easily follow them and debug individual requests without having to manually copy and paste the strings to a browser.

4)
Debug level 1 and 1024 only show the word "Request" or "Blocked" but no information about the method used.
Please add like this:
2012-12-15 16:50:41.422 00000d40 Request (GET): www.foo.se/bar/spacer
2012-12-15 16:50:41.422 00000d40 Request (POST): www.foo.se/bar/spacer
2012-12-15 16:50:41.422 00000d40 Crunch: Blocked (GET): http://www.foo.se/bar/spacer
2012-12-15 16:50:41.422 00000d40 Crunch: Blocked (POST): http://www.foo.se/bar/spacer

5)
Debug level 1024 currently only log that an URL has been blocked but not the reason.
Please add the reason, like this:
2012-12-15 16:50:55.111 00000d88 Crunch: Blocked (GET): http://www.example.com/nasty-ads/sponsor.gif {Nasty ads.}

6)
The sixth sub-request is not as important as the five ones above, but if it is easy to do, please add the server response code to the level 1 messages like this:
2012-12-15 16:51:42.144 00000e50 Request (GET:200): www.bar.se/baz
2012-12-15 16:51:42.144 00000e50 Request (POST:404): www.bar.se/gazonk

(There's no need to add a response code to the level 1024 message since the request haven't actually been sent to any server, so no true response code actually exist)

PS. I would much rather have the above items fixed than switching to using debug level 512 (common log format), since the latter won't show me the blocking reason, etc.

Discussion

  • Fabian Keil
    Fabian Keil
    2012-12-16

    • assigned_to: nobody --> fabiankeil
    • summary: Request: Show full clickable URL + method in MS-Win console --> Show full clickable URL + method in MS-Win console
    • status: open --> pending
     
  • Fabian Keil
    Fabian Keil
    2012-12-16

    Thanks for the suggestions.

    1) That seems reasonable to me but note that the protocol is only used for http:// requests.

    2) I believe that would be a side-effect of #1. If not, it's unlikely to happen without patches due to being Windows-specific.

    3) Windows-specific and I don't have a strong opinion on this.

    4) This would duplicate information that is already shown with other debug levels so I don't consider it useful.

    5) Privoxy 3.0.20 already has a new debug directive to show the applying actions which includes the block reason.

    6) This again would duplicate information. It also would require delaying the message until the response arrived.

    I don't see why you would have to switch debug levels when you can simply enable all the ones that provide information you care about.

     
  • Martin Olsson
    Martin Olsson
    2012-12-17

    1)
    I just want it to look consistent i all logs.

    4)
    This is a duplicate only if I enable 512 as well, and since I don't want to do that, it would be very useful to have this info in the level 1 log messages.

    If I remove level 1 and 1024 and enable 512 instead, I will see the method (and the response code), but I will no longer see what is being crunched in a highlighted fashion (and possibly not the blocking reason either).
    That's the reason I don't use 512 today.

    5)
    Neat. When will it be released?

    6)
    Yes, that delay could mess things up. Ignore this bullet.

    7)
    I want to EITHER use 1 + 1024 OR level 512. If I enable all three the log will be quite messy and have duplicates all over, and since some messages are delayed they are displayed out-of-order. The config even states that debug level 512 should be used by itself.

    I request bullet 4 since I don't want to enable level 512 as well just to get it.

    The alternative would be to use level 512 only, but my feature request #3596295 was closed and rejected, giving me no visibility of the crunches. ...so I still stress the need for item 4.