Taras, Great job! Please, find my comments inline. -- Raul Siles www.raulsiles.com
On Tue, Mar 16, 2010 at 2:00 PM, Andres Riancho <andres.rian...@gmail.com> wrote: > Taras, > > On Mon, Mar 15, 2010 at 7:33 PM, Taras <naplan...@gmail.com> wrote: >> >> Hi, all! >> >> I want to say some words about what I do in my branch =) > > Excellent :) > >> Simply I'm trying to make more clean and usable layout for our MITM >> Proxy tool. View for Intercept and history preview must be optimized for >> window area and purpose. >> >> http://lh3.ggpht.com/_Isq2bfVFv30/S56xtos-rnI/AAAAAAAABpA/u4o0CJg8XTM/text3885.png > > I like the all three of them, but I do have one question. The > "Request" is shown when the request is intercepted, then when the > response arrives the "Request" dissapears and the "Response" appears, > right? > [RS] I would add a field to the request in order to clearly specify if "http" or "https" is being used, and the TCP port involved. This can go in the top row containing the URL, but please, be sure it is always there. Eg.- https://domain.com:8088/URI. Regarding Andrés comments, I think it would be very useful to see the request associated to a response. To optimize the window space, a request can be a single window, but a response should contain a tab (or button) to display the associated request. this way you only see the response, but an easily see the contents of the request if interested. BTW, I'm not sure how you want to manage the area that says GET/POST payload, but please, if it is going to be used for both, GET and POST parameters, be sure there is some place where the HTTP method is specified (it can also use other methods: OPTIONS, HEAD, PUT, etc). >> I also want to show in response area only one view for body (not raw and >> HTML). So if we have syntax colorer then we use it. It not - simply show >> b/w body text. > > I think its a good way of using the restricted screen space. Its > not thaaaaat common that a user needs to read the response headers > (compared to the response body). > >> In Intercept/manual request view we need to see request and response in >> same time. Also we have whole window area and can split it. > > Hmmm, are you sure about this? I disagree. We had it like this in > the past, and it doesn't make much sense. > >> I also removed up,down, add and delete header buttons to free space. >> Now it is in popup menu (As I think these actions are not used oftentimes). > > Ok, > >> Furthermore for history preview we can show only raw (headers + body) >> layout so we will have only 2 tabs: Request and Response. > [RS] Andres suggestion is an option. I would be consistent between the format used in he Response window and the format for the history preview, and use the same layout for both: RAW or Body/Headers. > I think that the MITM Proxy should have all the same options that > the rest of the framework. If the users are used to doing "something" > with the request/response in the fuzzy request editor, they should be > able to do it with in MITM proxy also. My idea is that the > reqResViewer should be the same in all cases. > >> What do you think about it? >> >> >> -- >> Taras >> ---- >> "Software is like sex: it's better when it's free." - Linus Torvalds >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> W3af-develop mailing list >> W3af-develop@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/w3af-develop >> >> > > > > -- > Andrés Riancho > Founder, Bonsai - Information Security > http://www.bonsai-sec.com/ > http://w3af.sf.net/ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > W3af-develop mailing list > W3af-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/w3af-develop > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
