| Age | Commit message (Collapse) | Author |
|---|
|
to dale); espie@ ok
|
|
|
|
(okay theo, kettenis)
|
|
|
|
|
|
|
|
ETag (entity tag) header value. Instead of including
the file modification date, inode, file size, etc.
directly in the ETag header, return a SHA1 hash of
these values instead.
This SHA1 hash is initialized with a pseudorandom
secret, so that it's harder to brute force inode
numbers. This initialization secret is saved in a
file called "etag-state" in the httpd chroot logs/
directory, so that the ETag header values are consistent
across httpd restarts (if the secret were different
each time httpd started, ETags would change unnecessarily
and thereby cause caches to refresh unnecessarily).
An additional change is introduced: we add the dev
number to the hash when (and only when) we add the
inode number to the hash.
Before:
HTTP/1.1 200 OK
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.7-beta3
ETag: "b10d3-1e59-3e49cbe4"
In this case, we can tell the inode number of index.html
is is b10d3 hex.
After:
HTTP/1.1 200 OK
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.7-beta3
ETag: "3f3b3cb2ce2e278087960b3be6a6e9844166e371"
Idea and solution by deraadt@. OK deraadt@, henning@. Any
bugs are my fault :)
|
|
|
|
server code into the client; ok provos@
|
|
|
|
|
|
the base64 alphabet includes the characters '/', '+', and '=', it may
violate section 4 of RFC 1341, which says that these kinds of characters
must be quoted in order to be used as a header parameter. Pointed out
by Wouter Clarie (rimshot AT pandora DOT be).
My solution is not to quote the parameter (I'm afraid that will break
simple browsers) but to replace special characters with alphabetic
characters so that the resulting string is entirely alphanumeric. We
don't want to use hex here, the alphabet is too small.
"not too ugly for me" deraadt@, "a bit ugly but good enough" henning@,
"that might be better than quoting" wouter
|
|
|
|
extif>"whatever"
should not be the same as
extif="whatever"
but a syntax error.
|
|
installed.
Noticed by jmc@
|
|
|
|
|
|
favor of the GNU version), but it gets fixed anyways. ok mickey@
|
|
|
|
of it in kbd(8) to work correctly with such a keyboard.
Reminded by maja some time ago.
|
|
|
|
|
|
missing some keys at the moment.
|
|
|
|
some others, like the 712, will run with a regular ps/2 keyboard from your
average computer shop, and the hardware will convert the scancodes so that
they match the braindead gsc usage.
Thus, it makes no point carrying a specific set of keyboard layouts for gsckbd,
when in fact it's (almost) the same as for pckbd, with scancodes shuffled.
So, add a simple scheme to build gsckbd tables from the pckbd tables. This
brings all the international layouts from pckbd, but jp and br have extra
keys for which I don't know the scancodes, so the generated gsckbd layouts
are incomplete.
|
|
|
|
|
|
devices.
The ID module only purpose is to provide a small, unique, bitstring, which
was used for some copy-protection or licensing scheme under HP-UX.
Right now this driver is useless, as it provides no way to communicate
this information to userland, and only displays it while attaching, as such:
hilid0 at hil0 code 2: ID module
hilid0: security code 10 04 b4 41 ac 77 14 0f 41 00 00 00 00 00 00 00
hilid1 at hil0 code 3: ID module
hilid1: security code 10 04 b4 41 e3 b8 13 0f 41 00 00 00 00 00 00 00
Too bad it's not even good enough to feed the kernel random generator...
|
|
kernels to attach hilkbd0 (console keyboard) or hilms0 (main mouse) to
a specific device in the loop, by using UKC or compiling a new kernel.
Using this and the previous console changes, it is now possible on a loop
with multiple keyboards, to choose which keyboard will be the console
keyboard.
|
|
- only attach a keyboard as a console if it matches the PDC keyboard path
- on hil, as there can be multiple keyboards on the loop, attach only the
first hilkbd device configured as console keyboard. Right now this means
the one with the lowest hil code, which was the existing behaviour so far.
- do not try to switch to the wscons consdev structure early at all in
wscons_machdep, but rather wait for the console to be completely
configured (i.e. both wskbd and wsdisplay are attached) to switch.
With feedback and help from mickey@
|
|
save for the copyright message).
|
|
do not stick to u_int8_t when native word size can do the job better.
- Allow send_hildev_cmd() to return the command response buffer to its
caller, rather than forcing it to look at the guts of its parent device
softc... this will be needed shortly.
|
|
|
|
|
|
|
|
Until upgrades are available.
Oops, I said it!
|
|
|
|
Suggestion by Nick Holland out of comments by deraadt@ and miod@.
ok deraadt@ millert@
|
|
|
|
|
|
|
|
Instead, generate a random MIME boundary separator that is also
much longer, which makes it less likely to occur in the data.
Before:
HTTP/1.1 206 Partial Content
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.7-beta3
Content-Type: multipart/byteranges; boundary=3e4e7d648e6
where the first 6 hex digits of the boundary is the request
time and the last 4 hex digits of the boundary (48e6) is the PID
of the httpd process that served the request.
After:
HTTP/1.1 206 Partial Content
Server: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.7-beta3
Content-Type: multipart/byteranges; boundary=lqmQDSxeaFSosnx+R46M94slY7G5BKGVPIhCc4ffoW852Vz0RbOaLJfMCAHHTfvR
The boundary now consists of 48 pseudorandom bytes encoded into 64
base64 characters. This is in accordance with RFC 1341 section 7.2.1.
Based on conversations with deraadt@. OK deraadt@
|
|
stations such as the airport extreme to associate. Tested by
Ben Lovett.
|
|
|
|
|
|
|
|
|
|
Remove another dated comment about 3.1 to 3.2 upgrade.
|
|
|
|
|
