Re: [PATCH] Allow tagging requests with server address and/or port
[email protected] Mon, 25 Apr 2016 21:38:15 +0200
| Newsgroups | gmane.comp.web.privoxy.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============4596413808319638303== Content-Type: multipart/alternative; boundary="=_e3927d75702467549fdd36ea83ac4fe2" --=_e3927d75702467549fdd36ea83ac4fe2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fabian,Fabian Keil <[email protected]> wrote:> pursievro@fa= ke-box.com wrote:> > > Plea= se find attached (in-line and as attachment) a patch which allows to>= > tag a client's request with the port and/or the ip-address of the= privoxy> > server which handles the request.> >> > Ex= ample use case:> > > > privoxy listens on two addresses, e.g= . localhost:8118 and localhost:9119.> > By tagging the request wit= h> >> > This is for example useful to distinguish request ma= de through different> > hosts/ports.> > Thanks a lot for the= patch.> > I agree that something like this would be useful but th= ink it> could be simplified by using a single listen-address variable= > that allows to tag the request with address and port together.Ok.&g= t; Instead of creating a text representation of the listen-address> f= or each connection, it seems preferable to do it once after> binding= to the socket and simply look it up later on.The server socket is 'gene= rated' in bind_port(), file jbsockets.c. Following up the path we arrive= via bind_port_helper() andbind_ports_helper(), both file jcc.c, in list= en_loop(), also jcc.c. Thesocket is passed as a pointer argument from fu= nction to function.Adding the additional information of the listen-addre= ss and listen-portwould require it to be replaced by an array of structs= like struct server_state { ch= ar *server_ip_addr_str; jb_soc= ket fd;}However, even if we have the text representation in listen_loop(= ),How should we pass the information to compile_dynamic_pcrs_job_list(),= and set_privoxy_variables(), both file filters.c, where we actually want= to use that value? Both functions take a client_state as argument anduse= it to access the needed bits of information. So this seemed for me alog= ical route to take.Another possibility is to add an extra parameter toco= mpile_dynamic_pcrs_job_list() and set_privoxy_variables(), call itserver= _state, which contains all the information needed.Then, following the fl= ow from compile_dynamic_pcrs_job_list() upwards wearrive (for one possib= le path) at- header_tagger(), parsers.c- scan_headers(), parsers.c- sed(= ), parsers.c- parse_client_request(), jcc.c- chat(), jcc.c- serve(), jcc= .c- listen_loop() via pthread(), jcc.cso all these function get a additi= onal server_state argument, just topass it onwards.Last problem to tackl= e would be how to determine inside listen_loop()which socket accepted th= e client. Note that accept_connection() takesthe complete array of avail= able sockets from listen_loop(). So adding anadditional parameter server= _state* in addition to client_state* seemsnecessary to tell listen_loop(= ) which server socket it was.Yet another approach would be a hybrid of t= he one in the patch and theone discussed above:Only replacing the jb_soc= ket pointers/arrays in bind_port(),bind_port_helper(), bind_ports_helper= () and accept_connection() withpointers/arrays to struct server_state as= described above, adding a newfield char *server_addr in client_state (s= imilar as done in the patch)and setting this field in accept_connection= based on the server_statewhich accepted the client connection.So what d= o you think which one should I pursue?> Variables should be declared= at the beginning of the block> in which they are used.I'll fix that= in the next version of the patch.Thanks for the response.=0D=0A --=_e3927d75702467549fdd36ea83ac4fe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fabian,<br><br>Fabian Keil <[email protected]> wrote:<br>>= [email protected] wrote:<br>> &nbs= p; <br>> > Please find attached (in-line and as attachment) a patc= h which allows to<br>> > tag a client's request with the port and/= or the ip-address of the privoxy<br>> > server which handles the r= equest.<br>> ><br>> > Example use case:<br>> > <br>>= ; > privoxy listens on two addresses, e.g. localhost:8118 and localho= st:9119.<br>> > By tagging the request with<br>> ><br>> &= gt; This is for example useful to distinguish request made through diffe= rent<br>> > hosts/ports.<br>> <br>> Thanks a lot for the pat= ch.<br>> <br>> I agree that something like this would be useful bu= t think it<br>> could be simplified by using a single listen-address= variable<br>> that allows to tag the request with address and port t= ogether.<br><br>Ok.<br><br>> Instead of creating a text representatio= n of the listen-address<br>> for each connection, it seems preferable= to do it once after<br>> binding to the socket and simply look it up= later on.<br><br>The server socket is 'generated' in bind_port(), file= jbsockets.c. <br>Following up the path we arrive via bind_port_helper()= and<br>bind_ports_helper(), both file jcc.c, in listen_loop(), also jcc= .c. The<br>socket is passed as a pointer argument from function to funct= ion.<br>Adding the additional information of the listen-address and list= en-port<br>would require it to be replaced by an array of structs like <= br><br>struct server_state {<br> &nbs= p; char *server_ip_addr_str;<br> &nbs= p; jb_socket fd;<br>}<br><br>However, even if we have the text represent= ation in listen_loop(),<br>How should we pass the information to compile= _dynamic_pcrs_job_list(),<br>and set_privoxy_variables(), both file filt= ers.c, where we actually want<br>to use that value? Both functions take= a client_state as argument and<br>use it to access the needed bits of i= nformation. So this seemed for me a<br>logical route to take.<br><br>Ano= ther possibility is to add an extra parameter to<br>compile_dynamic_pcrs= _job_list() and set_privoxy_variables(), call it<br>server_state, which= contains all the information needed.<br><br>Then, following the flow fr= om compile_dynamic_pcrs_job_list() upwards we<br>arrive (for one possibl= e path) at<br>- header_tagger(), parsers.c<br>- scan_headers(), parsers.= c<br>- sed(), parsers.c<br>- parse_client_request(), jcc.c<br>- chat(),= jcc.c<br>- serve(), jcc.c<br>- listen_loop() via pthread(), jcc.c<br><b= r>so all these function get a additional server_state argument, just to<= br>pass it onwards.<br><br>Last problem to tackle would be how to determ= ine inside listen_loop()<br>which socket accepted the client. Note that= accept_connection() takes<br>the complete array of available sockets fr= om listen_loop(). So adding an<br>additional parameter server_state* in= addition to client_state* seems<br>necessary to tell listen_loop() whic= h server socket it was.<br><br><br>Yet another approach would be a hybri= d of the one in the patch and the<br>one discussed above:<br><br>Only re= placing the jb_socket pointers/arrays in bind_port(),<br>bind_port_helpe= r(), bind_ports_helper() and accept_connection() with<br>pointers/arrays= to struct server_state as described above, adding a new<br>field char *= server_addr in client_state (similar as done in the patch)<br>and settin= g this field in accept_connection based on the server_state<br>which acc= epted the client connection.<br><br><br>So what do you think which one s= hould I pursue?<br><br><br>> Variables should be declared at the begi= nning of the block<br>> in which they are used.<br><br>I'll fix that= in the next version of the patch.<br><br>Thanks for the response.<br>= =0D=0A --=_e3927d75702467549fdd36ea83ac4fe2-- --===============4596413808319638303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z --===============4596413808319638303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ijbswa-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ijbswa-developers --===============4596413808319638303==--