Re: [MERGE] Use libcap instead of direct linux capability syscalls

[Amos Jeffries]

Henrik Nordstrom wrote:

fre 2009-10-16 klockan 02:04 +0200 skrev Henrik Nordstrom:

fre 2009-10-16 klockan 11:03 +1300 skrev Amos Jeffries:

/* NP: keep these two if-endif separate. Non-Linux work perfectly well 

Sorry.. thought I had fixed that already..


+#define PUSH_CAP(cap) cap_list[ncaps++] = (cap)

I can just see that converting to: 
CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ...

Nope.. preprocessor is tokens based. But as this macro is farily simple
now it can just as well be expanded. I think the plan was to eventually
C++ encapsulate these details, but that's overkill here.

Updated patch attaced.



Crap. libcap on centos is not usable.

Regards
Henrik



Um, is that function libcap2 specific?

It may be related to the LIBCAP_BROKEN identifier or another such test 
for the specific function may be worth adding...


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19
  Current Beta Squid 3.1.0.14

Re: WebSockets negotiation over HTTP

[Amos Jeffries]

Ian Hickson wrote:

On Wed, 14 Oct 2009, Amos Jeffries wrote:
4.1.12 prescribes semi-implicitly that HTTP/1.0 and HTTP/1.2 etc are not 
compatible. Maybe thats what you want. *very* minor enhancement would be 
to make that explicitly stated.


I've added a note to this effect.



4.1.13 still has a fragility issue in that it assumes the Upgrade: and
Connection: headers will retain both their specific sending order and be
the very first headers in the reply. It will work in most situations, but
proxies which 'correct' the headers order to have Date: first will kill
WebSockets.


That's intentional; such proxies don't know about Web Sockets (if they 
did, they wouldn't be modifying the headers!) and thus clearly can't 
really be trusted to route the traffic unmodified.


At this point of the handshake the client is the only software which 
knows its using WebSockets.
The server may validate-parse the headers mime syntax before sub-parsing 
the request line. At this point all its seen is the GET and HTTP/1.1.


So... the server and any middleware will be in a state right now 
thinking that HTTP/1.1 is in use and will do appropriate HTTP/1.1 header 
alterations.


It is not until the server reply accepting the Upgrade: request is 
received by middleware that WebSockets protocol actions can start happening.




4.1 14 thru 4.1.23 appear to be a very conflated description of parsing 
the headers.


It seems to me that referencing rfc2616 section 4.2 should be sufficient 
for the parse


Unfortunately, HTTP doesn't define how to parse headers. It defines the 
semantics of valid headers, but doesn't say, e.g., what headers are 
present in the following:


   HTTP/1.1 200 OK
   : Bar
   Foo
   Quux


Section 4.2 is clear:
 "Each header field consists of a name followed by a colon (":") and 
the field value. Field names are case-insensitive."


  NP: WebSockets as of draft-49 requires (1.2) "The first three lines 
in each case are hard-coded (the exact case and order matters)" which is 
a breach of the final statement above. That final statement permits 
middeleware to uppercase or CamelCase the headers on a whim without 
altering their meaning.


References RFC822 section 3.1 for the BNF. Which states:
 " B.1.  SYNTAX

 message =   *field *(CRLF *text)

 field   =field-name ":" [field-body] CRLF

 field-name  =  1*

 field-body  =   *text [CRLF LWSP-char field-body]
"
...
"
  C.1.1.  FIELD NAMES

These now must be a sequence of  printable  characters.   They
may not contain any LWSP-chars.
"

 ... which requires a minimum of one ASCII byte header names which may 
not include ':' or whitespace or non-printables.


 NP: WebSockets draft-49 changes the bytes to UNICODE format and 
permits non-printables which are not LF or CR.



In your above demo request is HTTP/1.1 invalid:
 * first header line has no token in the field-name portion,
 * second line has CRLF in the name portion,
 * third line has zero-byte name portion.

Any one of which will be either dropped by existing middleware or 
handled as HTTP/0.9 with body content:

  : Bar
  Foo
  Quux

The first handling method is good the second may be a major headache.

Since you have spec'd that only valid HTTP/1.1 is acceptable this will 
be dropped by any WebSockets aware software even if its accepted by 
WebSockets.


For completeness the rest of rfc822sect3.1 used by rfc2616 specs:
"
 B.2.  SEMANTICS

  Headers occur before the message body and are terminated  by
 a null line (i.e., two contiguous CRLFs).

  A line which continues a header field begins with a SPACE or
 HTAB  character,  while  a  line  beginning a field starts with a
 printable character which is not a colon.

  A field-name consists of one or  more  printable  characters
 (excluding  colon,  space, and control-characters).  A field-name
 MUST be contained on one line.  Upper and lower case are not dis-
 tinguished when comparing field-names.
"

.. the third clause there prohibits headers like your example Foo:

   Foo
   : header text

Supporting the second clause (LWS) will not affect the client sent data. 
But will help WebSockets cope with headers using very long Cookie data 
and long auth credentials.




For Web Sockets I would like to have well-defined processing in the face 
of any input, even invalid input. I'd also like to not require that the 
processing for headers be as complicated as HTTP's (with continuation 
lines, multiple headers being merged, etc).


Understood. I'm hoping the above spec 2616 + 822 segments are 
sufficiently clear for you on what is and is not permitted on the headers.


Things which are not valid HTTP/1.1 as above are of course badly broken 
WebSockets as well. You can spec as a broad cover that non-valid 
HTTP/1.1 is a fail connection.




and do away with 4.1.15 through 4.1.21. Similar to the way 4.1.23 
mentions www-auth "Obtain [h

Re: [MERGE] Use libcap instead of direct linux capability syscalls

[Henrik Nordstrom]

fre 2009-10-16 klockan 02:04 +0200 skrev Henrik Nordstrom:
> fre 2009-10-16 klockan 11:03 +1300 skrev Amos Jeffries:
> 
> > /* NP: keep these two if-endif separate. Non-Linux work perfectly well 
> 
> Sorry.. thought I had fixed that already..
> 
> > +#define PUSH_CAP(cap) cap_list[ncaps++] = (cap)
> > 
> > I can just see that converting to: 
> > CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ...
> 
> Nope.. preprocessor is tokens based. But as this macro is farily simple
> now it can just as well be expanded. I think the plan was to eventually
> C++ encapsulate these details, but that's overkill here.
> 
> Updated patch attaced.


Crap. libcap on centos is not usable.

Regards
Henrik

Hudson build is back to normal: 3.HEAD-amd64-CentOS-5.3 #156

[noc]

See