Re: [PATCH] Allow tagging requests with server address and/or port

--===============0771227337358886335==
Content-Type: multipart/signed; micalg=pgp-sha256;
	boundary="Sig_/B3dUwr3nkX=/PEwQLfVs+lT";
	protocol="application/pgp-signature"

--Sig_/B3dUwr3nkX=/PEwQLfVs+lT
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

[email protected] wrote:

> Fabian Keil <[email protected]> wrote:
> > [email protected] wrote:
> >     =20
> > > Please 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 pri=
voxy
> > > server which handles the request.
> > >
> > > Example use case:
> > >
> > > privoxy listens on two addresses, e.g. localhost:8118 and localhost:9=
119.
> > > By tagging the request with
> > >
> > > This is for example useful to distinguish request made through differ=
ent
> > > hosts/ports.
> >
> > Thanks a lot for the patch.
> >
> > I agree that something like this would be useful but think it
> > could be simplified by using a single listen-address variable
> > that allows to tag the request with address and port together.
>=20
> Ok.
>=20
> > Instead of creating a text representation of the listen-address
> > for 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 'generated' in bind_port(), file jbsockets.c.
> Following up the path we arrive via bind_port_helper() and
> bind_ports_helper(), both file jcc.c, in listen_loop(), also jcc.c. The
> socket is passed as a pointer argument from function to function.
> Adding the additional information of the listen-address and listen-port
> would require it to be replaced by an array of structs like
>=20
> struct server_state {
>         char *server_ip_addr_str;
>         jb_socket fd;
> }
>=20
> 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 and
> use it to access the needed bits of information. So this seemed for me a
> logical route to take.
>=20
> Another possibility is to add an extra parameter to
> compile_dynamic_pcrs_job_list() and set_privoxy_variables(), call it
> server_state, which contains all the information needed.
>=20
> Then, following the flow from compile_dynamic_pcrs_job_list() upwards we
> arrive (for one possible 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.c
>=20
> so all these function get a additional server_state argument, just to
> pass it onwards.
>=20
> Last problem to tackle would be how to determine inside listen_loop()
> which socket accepted the client. Note that accept_connection() takes
> the complete array of available sockets from listen_loop(). So adding an
> additional parameter server_state* in addition to client_state* seems
> necessary to tell listen_loop() which server socket it was.
>=20
>=20
> Yet another approach would be a hybrid of the one in the patch and the
> one discussed above:
>=20
> Only replacing the jb_socket pointers/arrays in bind_port(),
> bind_port_helper(), bind_ports_helper() and accept_connection() with
> pointers/arrays to struct server_state as described above, adding a new
> field char *server_addr in client_state (similar as done in the patch)
> and setting this field in accept_connection based on the server_state
> which accepted the client connection.

Unless I miss something, accept_connection() should be able to set
the a csp->listen_addr by using the socket index (the i in fds[i]) on
csp->config->haddr[] and csp->config->hport[].

BTW, your MUA seems to declare HTML as text which causes rendering
issues like this:
https://sourceforge.net/p/ijbswa/mailman/ijbswa-developers/?viewmonth=3D201=
604

It would be great if you could fix this, preferable by using plain
text mails without any HTML.

Fabian

--Sig_/B3dUwr3nkX=/PEwQLfVs+lT
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXH4qlAAoJEGkYIpGLojccWZYQAImyl91eEXY9XC+cAu047PGy
D6LKLtHL355LDHs57AaRaCgq8gWe+BpC1SmdzAFxt0n6ftA38pPPyH0tW4XMF3dj
Z7cM1z1yopBnWNhUsAIUTruFTlp/etaEDXfaBzJT3ubsz/Vx2fU42HN40rPw85uE
NmOrITAAX2Q4C0xhbjdKjaTxrw+Mu/xCLQpLusMDs3iPb3xsjHD3RNHzqSAH/6Te
lXkXD/7J9R5eifdlU/M9J1G+ZvMVbTzSzgk54XHsheXz7/suiaD/UUYhMEQbTJ3k
Q6mwaY6m16Yk+AjTDj3HiMTUN9SEz8evOZ5fLDTriTVmyzyH2lE4pW7SoaqANsQ9
NembWsoyGhVEHeoe0bYbRHoxyvthuUARTxfD01CbeoyNvqaH+/ppJmeJOzyUX+Nv
KuJIfjGuiyXa/5kTZ+wunsVrzb8Ws4h5GAHguQfc1rquGwXO2gT5ZqmhSszx0paL
aT0BntjmqoEIvA41x4fxKcOFCR8O6NIo8NvGdOPqJUCHD0g/uiWeGMxQ1WdgNie2
hMwFaTvtA3sYyvG+jHBzg2iltL7Zr+zm/T6fyacJq7GiZase2L0xLw/SlFJHDerd
51suaEnOR4jVKr6JY4Ejof1uWHNVnrxXc1YJDjt7o0DMzsW5aekLUozD9p9K24xi
uHngq50F8w1WaAWg19XY
=eZE6
-----END PGP SIGNATURE-----

--Sig_/B3dUwr3nkX=/PEwQLfVs+lT--


--===============0771227337358886335==
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
--===============0771227337358886335==
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

--===============0771227337358886335==--