SO_REUSEPORT in the children processes
Hi all,
the patch about SO_REUSEPORT proposed by Yingqi Lu in [1] and discussed in
[2] uses listeners buckets to address a defect [3] in the current linux
implementation (his patch goes beyond SO_REUSEPORT though, and suggests a
new MPM even when the option is not available).
Should this defect be addressed by linux folks, the event/worker/prefork
MPMs could take full advantage of the option (linux-3.9+) with quite simple
modifications of the current code.
I'm proposing here the corresponding patch.
The idea is to re-create and re-bind/listen the parent's listeners sockets
for each child process, when starting, before dropping priviledges.
For this, the patch introduces a new ap_reopen_listeners() function (meant
to be called by each child) to do the job on the inherited listeners. It
does nothing unless HAVE_SO_REUSEPORT is defined.
The advantage of this approach is that no accept mutex is needed anymore
(each child has its own sockets), hence the SAFE_ACCEPT macros can do
nothing when HAVE_SO_REUSEPORT is defined.
The new (incoming) connections are evenly distributed accross the children
for all the listners (as assured by Linux when SO_REUSEPORT is used).
I'm proposing the patch here so that everyone can figure out whether
SO_REUSEPORT per se needs its own MPM or not (once/if the defect is fixed).
The option seems to be quite easily pluggable to existing MPMs (no ABI
change), and I don't see an advantage to not using it when available (and
working).
Also, FreeBSD has an implementation of SO_REUSEPORT,
however
I couldn't find whether it has the same scheduling garantee
or not
(at least I guess the accept mutex can be avoided too).
Regarding the linux kernel defect, is someone aware of a fix/work on that
in the latest versions?
Finally, about the accept mutex, mpm event seems to work well without any,
why prefork and worker would need one (both poll() all the listeners in a
single thread, while other children can do the same)?
The patch follows and is attached.
It can already be tested with a workaround against the defect: don't let
perform_idle_server_maintenance() create/stop children after startup (eg.
StartServers, ServerLimit, Min/MaxSpareServers using the same value).
Thoughts, feedbacks welcome.
Regards,
Yann.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55897#c7
[2]
http://mail-archives.apache.org/mod_mbox/httpd-bugs/201312.mbox/%3cbug-55897-7...@https.issues.apache.org/bugzilla/%3E
[3] http://lwn.net/Articles/542629/ and http://lwn.net/Articles/542738/
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1575322)
+++ server/mpm/event/event.c(working copy)
@@ -2356,6 +2356,13 @@ static void child_main(int child_num_arg)
/*stuff to do before we switch id's, so we have permissions. */
ap_reopen_scoreboard(pchild, NULL, 0);
+rv = ap_reopen_listeners(pchild, num_listensocks);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf, APLOGNO()
+ Couldn't re-open listeners);
+clean_child_exit(APEXIT_CHILDFATAL);
+}
+
if (ap_run_drop_privileges(pchild, ap_server_conf)) {
clean_child_exit(APEXIT_CHILDFATAL);
}
Index: server/mpm/prefork/prefork.c
===
--- server/mpm/prefork/prefork.c(revision 1575322)
+++ server/mpm/prefork/prefork.c(working copy)
@@ -271,7 +271,9 @@ static void accept_mutex_off(void)
* multiple Listen statements. Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
* when it's safe in the single Listen case.
*/
-#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT
+#if HAVE_SO_REUSEPORT
+#define SAFE_ACCEPT(stmt)
+#elif defined(SINGLE_LISTEN_UNSERIALIZED_ACCEPT)
#define SAFE_ACCEPT(stmt) do {if (ap_listeners-next) {stmt;}} while(0)
#else
#define SAFE_ACCEPT(stmt) do {stmt;} while(0)
@@ -536,6 +538,13 @@ static void child_main(int child_num_arg)
clean_child_exit(APEXIT_CHILDFATAL);
}
+status = ap_reopen_listeners(pchild, num_listensocks);
+if (status != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_EMERG, status, ap_server_conf,
APLOGNO()
+ Couldn't re-open listeners);
+clean_child_exit(APEXIT_CHILDFATAL);
+}
+
if (ap_run_drop_privileges(pchild, ap_server_conf)) {
clean_child_exit(APEXIT_CHILDFATAL);
}
Index: server/mpm/worker/worker.c
===
--- server/mpm/worker/worker.c(revision 1575322)
+++ server/mpm/worker/worker.c(working copy)
@@ -220,7 +220,9 @@ static apr_os_thread_t *listener_os_thread;
/* Locks for accept serialization */
static apr_proc_mutex_t *accept_mutex;
-#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT
+#if HAVE_SO_REUSEPORT
+#define SAFE_ACCEPT(stmt)
+#elif defined(SINGLE_LISTEN_UNSERIALIZED_ACCEPT)
#define SAFE_ACCEPT(stmt) (ap_listeners-next ?
Re: SO_REUSEPORT in the children processes
Am 07.03.2014 18:07, schrieb Yann Ylavic can you please post plaintext instead HTML to lists for me such messages are unreadable after medical operations on both eyes because you override my MUA font settings signature.asc Description: OpenPGP digital signature
Re: SO_REUSEPORT in the children processes
On Fri, Mar 7, 2014 at 6:24 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 07.03.2014 18:07, schrieb Yann Ylavic
can you please post plaintext instead HTML to lists
for me such messages are unreadable after medical operations
on both eyes because you override my MUA font settings
Sorry, this was posted from gmail...
Here is the plain text.
***
Hi all,
the patch about SO_REUSEPORT proposed by Yingqi Lu in [1] and
discussed in [2] uses listeners buckets to address a defect [3] in the
current linux implementation (his patch goes beyond SO_REUSEPORT
though, and suggests a new MPM even when the option is not available).
Should this defect be addressed by linux folks, the
event/worker/prefork MPMs could take full advantage of the option
(linux-3.9+) with quite simple modifications of the current code.
I'm proposing here the corresponding patch.
The idea is to re-create and re-bind/listen the parent's listeners
sockets for each child process, when starting, before dropping
priviledges.
For this, the patch introduces a new ap_reopen_listeners() function
(meant to be called by each child) to do the job on the inherited
listeners. It does nothing unless HAVE_SO_REUSEPORT is defined.
The advantage of this approach is that no accept mutex is needed
anymore (each child has its own sockets), hence the SAFE_ACCEPT macros
can do nothing when HAVE_SO_REUSEPORT is defined.
The new (incoming) connections are evenly distributed accross the
children for all the listners (as assured by Linux when SO_REUSEPORT
is used).
I'm proposing the patch here so that everyone can figure out whether
SO_REUSEPORT per se needs its own MPM or not (once/if the defect is
fixed).
The option seems to be quite easily pluggable to existing MPMs (no ABI
change), and I don't see an advantage to not using it when available
(and working).
Also, FreeBSD has an implementation of SO_REUSEPORT,
however
I couldn't find whether it has the same scheduling garantee
or not
(at least I guess the accept mutex can be avoided too).
Regarding the linux kernel defect, is someone aware of a fix/work on
that in the latest versions?
Finally, about the accept mutex, mpm event seems to work well without
any, why prefork and worker would need one (both poll() all the
listeners in a single thread, while other children can do the same)?
The patch follows and is attached.
It can already be tested with a workaround against the defect: don't
let perform_idle_server_maintenance() create/stop children after
startup (eg. StartServers, ServerLimit, Min/MaxSpareServers using the
same value).
Thoughts, feedbacks welcome.
Regards,
Yann.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55897#c7
[2]
http://mail-archives.apache.org/mod_mbox/httpd-bugs/201312.mbox/%3cbug-55897-7...@https.issues.apache.org/bugzilla/%3E
[3] http://lwn.net/Articles/542629/ and http://lwn.net/Articles/542738/
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1575322)
+++ server/mpm/event/event.c(working copy)
@@ -2356,6 +2356,13 @@ static void child_main(int child_num_arg)
/*stuff to do before we switch id's, so we have permissions. */
ap_reopen_scoreboard(pchild, NULL, 0);
+rv = ap_reopen_listeners(pchild, num_listensocks);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_EMERG, rv, ap_server_conf, APLOGNO()
+ Couldn't re-open listeners);
+clean_child_exit(APEXIT_CHILDFATAL);
+}
+
if (ap_run_drop_privileges(pchild, ap_server_conf)) {
clean_child_exit(APEXIT_CHILDFATAL);
}
Index: server/mpm/prefork/prefork.c
===
--- server/mpm/prefork/prefork.c(revision 1575322)
+++ server/mpm/prefork/prefork.c(working copy)
@@ -271,7 +271,9 @@ static void accept_mutex_off(void)
* multiple Listen statements. Define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
* when it's safe in the single Listen case.
*/
-#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT
+#if HAVE_SO_REUSEPORT
+#define SAFE_ACCEPT(stmt)
+#elif defined(SINGLE_LISTEN_UNSERIALIZED_ACCEPT)
#define SAFE_ACCEPT(stmt) do {if (ap_listeners-next) {stmt;}} while(0)
#else
#define SAFE_ACCEPT(stmt) do {stmt;} while(0)
@@ -536,6 +538,13 @@ static void child_main(int child_num_arg)
clean_child_exit(APEXIT_CHILDFATAL);
}
+status = ap_reopen_listeners(pchild, num_listensocks);
+if (status != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_EMERG, status, ap_server_conf, APLOGNO()
+ Couldn't re-open listeners);
+clean_child_exit(APEXIT_CHILDFATAL);
+}
+
if (ap_run_drop_privileges(pchild, ap_server_conf)) {
clean_child_exit(APEXIT_CHILDFATAL);
}
Index: server/mpm/worker/worker.c
===
--- server/mpm/worker/worker.c(revision 1575322)
+++
Re: SO_REUSEPORT in the children processes
Sorry, this was posted from gmail... FWIW I did not really see the distinctive HTML look and feel reading it on gmail.
Re: SO_REUSEPORT in the children processes
On Fri, Mar 7, 2014 at 6:35 PM, Eric Covener cove...@gmail.com wrote: Sorry, this was posted from gmail... FWIW I did not really see the distinctive HTML look and feel reading it on gmail. I have none... and won't uncheck the Plain text mode anymore. Otherwise it's almost impossible to copy/paste without erratic result. It looks and feels a bit like it wants :p
Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list, that use of HTML is something to apologize for? With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? He can -- ought to be able to -- adjust his MUA to use his font-preferences over whatever may be specified in the incoming email. I'd ask this question on /any/ mailing list, but it seems especially ironic among developers of Apache httpd -- software meant to distribute content, that is most often written in HTML... Granted, some HTML can be offensive even to the healthy eyes -- and ought to be viewed as impolite (not that Yann's was anything of the kind). But to request, as Reindl did, that /all/ postings -- from all participants -- be in plain text, seems rather overbearing... Here is the plain text. Wouldn't it be better to send such a duplication to Reindl /personally/? To avoid this becoming a list-wide flame war, I ask for the powers running this list to convene and hand us the law: either HTML is acceptable (my own preference), or it is not (in which case it should be bounced back by the mailing list software with an appropriate message). -mi
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Am 07.03.2014 18:58, schrieb Mikhail T.: On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list that use of HTML is something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only https://www.google.at/search?q=mailing+list+etiquette+no+html _ http://www.apache.org/foundation/mailinglists.html Note: Spam filters don't like messages with empty Subjects; just use e.g. subscribe or unsubscribe. Spam filters are also more likely to reject HTML-formatted messages; please use plain text With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting signature.asc Description: OpenPGP digital signature
Logging multiple values for the same cookie name?
In working through this code, I realized that you may have multiple cookie
headers of multiple values for the same cookie name.
Mark Thomas looked at the spec for me and determined they would be entirely
permissible by RFC 6265 S4.2.2. But today we simply log one and done.
I don't want to hold up 2.4 or 2.2 for such an issue, but would like to
correct it in the near-term. The discussion question is; how to indicate a
value list rather than a value in our logging?
On Mar 7, 2014 2:57 PM, wr...@apache.org wrote:
Author: wrowe
Date: Fri Mar 7 20:56:24 2014
New Revision: 1575400
URL: http://svn.apache.org/r1575400
Log:
Clean up the cookie logging parser to recognize only the cookie=value
pairs,
not valueless cookies. This refactors multiple passes over the same string
buffer into a single pass parser.
Submitted by: wrowe
Reviewed by: rpluem, jim
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/loggers/mod_log_config.c
Modified: httpd/httpd/trunk/CHANGES
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1575400r1=1575399r2=1575400view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Fri Mar 7 20:56:24 2014
@@ -1,6 +1,10 @@
-*- coding:
utf-8 -*-
Changes with Apache 2.5.0
+ *) Clean up cookie logging with fewer redundant string parsing passes.
+ Log only cookies with a value assignment.
+ [William Rowe, Ruediger Pluem, Jim Jagielski]
+
*) mod_ssl: Do not perform SNI / Host header comparison in case of a
forward proxy request. [Ruediger Pluem]
Modified: httpd/httpd/trunk/modules/loggers/mod_log_config.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/loggers/mod_log_config.c?rev=1575400r1=1575399r2=1575400view=diff
==
--- httpd/httpd/trunk/modules/loggers/mod_log_config.c (original)
+++ httpd/httpd/trunk/modules/loggers/mod_log_config.c Fri Mar 7 20:56:24
2014
@@ -543,14 +543,24 @@ static const char *log_cookie(request_re
while ((cookie = apr_strtok(cookies, ;, last1))) {
char *name = apr_strtok(cookie, =, last2);
-if (name) {
-char *value = name + strlen(name) + 1;
-apr_collapse_spaces(name, name);
+/* last2 points to the next char following an '=' delim,
+ or the trailing NUL char of the string */
+char *value = last2;
+if (name *name value *value) {
+char *last = value - 2;
+/* Move past leading WS */
+name += strspn(name, \t);
+while (last = name apr_isspace(*last)) {
+*last = '\0';
+--last;
+}
if (!strcasecmp(name, a)) {
-char *last;
-value += strspn(value, \t); /* Move past leading
WS */
-last = value + strlen(value) - 1;
+/* last1 points to the next char following the ';'
delim,
+ or the trailing NUL char of the string */
+last = last1 - (*last1 ? 2 : 1);
+/* Move past leading WS */
+value += strspn(value, \t);
while (last = value apr_isspace(*last)) {
*last = '\0';
--last;
@@ -559,6 +569,7 @@ static const char *log_cookie(request_re
return ap_escape_logitem(r-pool, value);
}
}
+/* Iterate the remaining tokens using apr_strtok(NULL, ...) */
cookies = NULL;
}
}
Re: Logging multiple values for the same cookie name?
* William A. Rowe Jr. wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I don't want to hold up 2.4 or 2.2 for such an issue, but would like to correct it in the near-term. The discussion question is; how to indicate a value list rather than a value in our logging? I'd suggest separating the values with semicolons. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: Logging multiple values for the same cookie name?
On Fri, Mar 7, 2014 at 10:29 PM, André Malo n...@perlig.de wrote: * William A. Rowe Jr. wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I don't want to hold up 2.4 or 2.2 for such an issue, but would like to correct it in the near-term. The discussion question is; how to indicate a value list rather than a value in our logging? I'd suggest separating the values with semicolons. +1
Re: Logging multiple values for the same cookie name?
On Fri, Mar 7, 2014 at 10:25 PM, William A. Rowe Jr. wmr...@gmail.com wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I can't presume how far you plan to handle the multiple cookie headers, but should you handle Cookie: name1=value1, name2=value2 as two distinct cookies (like comma separated headers defined by the HTTP RFC), it's good to know that most (if not all) user-agents won't, mostly because applications (cookie setters) won't either quote Set-Cookie values or attributes containing comma (double-quotes were not defined with cookies version 0). As a consequence, the above is commonly considered a single cookie named [name1] with value [value1, name2=value2]... Regards, Yann.
Re: Logging multiple values for the same cookie name?
On Mar 7, 2014 4:50 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Mar 7, 2014 at 10:25 PM, William A. Rowe Jr. wmr...@gmail.com wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I can't presume how far you plan to handle the multiple cookie headers, but should you handle Cookie: name1=value1, name2=value2 as two distinct cookies (like comma separated headers defined by the HTTP RFC), it's good to know that most (if not all) user-agents won't, mostly because applications (cookie setters) won't either quote Set-Cookie values or attributes containing comma (double-quotes were not defined with cookies version 0). As a consequence, the above is commonly considered a single cookie named [name1] with value [value1, name2=value2]... Did you mean comma? Or semicolon?
Re: Logging multiple values for the same cookie name?
On Sat, Mar 8, 2014 at 12:06 AM, William A. Rowe Jr. wmr...@gmail.com wrote: On Mar 7, 2014 4:50 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Mar 7, 2014 at 10:25 PM, William A. Rowe Jr. wmr...@gmail.com wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I can't presume how far you plan to handle the multiple cookie headers, but should you handle Cookie: name1=value1, name2=value2 as two distinct cookies (like comma separated headers defined by the HTTP RFC), it's good to know that most (if not all) user-agents won't, mostly because applications (cookie setters) won't either quote Set-Cookie values or attributes containing comma (double-quotes were not defined with cookies version 0). As a consequence, the above is commonly considered a single cookie named [name1] with value [value1, name2=value2]... Did you mean comma? Or semicolon? Comma yes. Semicolon is the only de facto cookie separator.
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
On Fri, 2014-03-07 at 12:58 -0500, Mikhail T. wrote: On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list, that use of HTML is something to apologize for? With all due sympathies to Reindl's medical Absolutely no apology required Harald is just a system admin subscribed to this http developer list, he has no association with Apache Software Foundation, he has been warned about playing net cop where he has no authority to do so before, ignore him. signature.asc Description: This is a digitally signed message part
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
Harry, you have been warned before, dont bring your antics onto this list, this is about the only list you have been most well behaved on, unlike others, please remember our previous conversations. If you think a posters post violates some RFC, ignore it, or take it up with him in private, do not pollute this list with your bullshit. Thank you :) On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald wrote: Am 07.03.2014 18:58, schrieb Mikhail T.: On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list that use of HTML is something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only https://www.google.at/search?q=mailing+list+etiquette+no+html _ http://www.apache.org/foundation/mailinglists.html Note: Spam filters don't like messages with empty Subjects; just use e.g. subscribe or unsubscribe. Spam filters are also more likely to reject HTML-formatted messages; please use plain text With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting attachment: face-smile.png signature.asc Description: This is a digitally signed message part
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
what exactly is your personal problem? can you please post plaintext instead HTML to lists you did see the word please? for me such messages are unreadable after medical operations on both eyes because you override my MUA font settings you understood that reason? i follow that thread longer honestly interested there where a few HTML respones and *all* oft hem left unread because they contained a lot of content he has been warned about playing net cop who do you think you are calling others net cop because they ask for easier readable posts while you are the one proven to playing net cop due maintaining a RBL? Is it written anywhere in the bylaws of this mailing list is the response you should have been attacking Am 08.03.2014 00:39, schrieb Noel Butler: Harry, you have been warned before, dont bring your antics onto this list, this is about the only list you have been most well behaved on, unlike others, please remember our previous conversations. If you think a posters post violates some RFC, ignore it, or take it up with him in private, do not pollute this list with your bullshit. Thank you :) On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald wrote: Am 07.03.2014 18:58, schrieb Mikhail T.: On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list that use of HTML is something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only https://www.google.at/search?q=mailing+list+etiquette+no+html _ http://www.apache.org/foundation/mailinglists.html Note: Spam filters don't like messages with empty Subjects; just use e.g. subscribe or unsubscribe. Spam filters are also more likely to reject HTML-formatted messages; please use plain text With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting signature.asc Description: OpenPGP digital signature
Re: Logging multiple values for the same cookie name?
So I am happy to agree with the semicolon list delimiter for logging. On Mar 7, 2014 5:09 PM, Yann Ylavic ylavic@gmail.com wrote: On Sat, Mar 8, 2014 at 12:06 AM, William A. Rowe Jr. wmr...@gmail.com wrote: On Mar 7, 2014 4:50 PM, Yann Ylavic ylavic@gmail.com wrote: On Fri, Mar 7, 2014 at 10:25 PM, William A. Rowe Jr. wmr...@gmail.com wrote: In working through this code, I realized that you may have multiple cookie headers of multiple values for the same cookie name. Mark Thomas looked at the spec for me and determined they would be entirely permissible by RFC 6265 S4.2.2. But today we simply log one and done. I can't presume how far you plan to handle the multiple cookie headers, but should you handle Cookie: name1=value1, name2=value2 as two distinct cookies (like comma separated headers defined by the HTTP RFC), it's good to know that most (if not all) user-agents won't, mostly because applications (cookie setters) won't either quote Set-Cookie values or attributes containing comma (double-quotes were not defined with cookies version 0). As a consequence, the above is commonly considered a single cookie named [name1] with value [value1, name2=value2]... Did you mean comma? Or semicolon? Comma yes. Semicolon is the only de facto cookie separator.
Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)
This will be dealt with off list On 08/03/2014 09:51, Reindl Harald wrote: what exactly is your personal problem? can you please post plaintext instead HTML to lists you did see the word please? for me such messages are unreadable after medical operations on both eyes because you override my MUA font settings you understood that reason? i follow that thread longer honestly interested there where a few HTML respones and *all* oft hem left unread because they contained a lot of content he has been warned about playing net cop who do you think you are calling others net cop because they ask for easier readable posts while you are the one proven to playing net cop due maintaining a RBL? Is it written anywhere in the bylaws of this mailing list is the response you should have been attacking Am 08.03.2014 00:39, schrieb Noel Butler: Harry, you have been warned before, dont bring your antics onto this list, this is about the only list you have been most well behaved on, unlike others, please remember our previous conversations. If you think a posters post violates some RFC, ignore it, or take it up with him in private, do not pollute this list with your bullshit. Thank you :) On Fri, 2014-03-07 at 19:13 +0100, Reindl Harald wrote: Am 07.03.2014 18:58, schrieb Mikhail T.: On 07.03.2014 12:28, Yann Ylavic wrote: Sorry, this was posted from gmail... Is it written anywhere in the bylaws of this mailing list that use of HTML is something to apologize for? nearly any mailing-list has it written clear, some even reject HTML and on some others you get warned by the owner (postfix as example) https://www.google.com/search?q=mailing+list+etiquette+plaintext+only [1] https://www.google.at/search?q=mailing+list+etiquette+no+html [2] _ http://www.apache.org/foundation/mailinglists.html [3]Note: Spam filters don't like messages with empty Subjects; just use e.g. subscribe or unsubscribe. Spam filters are also more likely to reject HTML-formatted messages; please use plain text With all due sympathies to Reindl's medical condition, why must we -- in the second decade of the 21st century -- deny ourselves the means of expression afforded by HTML on this list? because the message had no single HTML formatting and was written in plain but as HTML may be a godd reason it hardly makes sense to write email in HTML, they just explode after some replies/quotes and forwardings with different clients while a conversation in plaintext survises thousands of replies without lose a sane quoting Links: -- [1] https://www.google.com/search?q=mailing+list+etiquette+plaintext+only [2] https://www.google.at/search?q=mailing+list+etiquette+no+html [3] http://www.apache.org/foundation/mailinglists.html
