RFC2616 sections 4.4 and 14.16:
* Cannot use Content-Length with non-identity Transfer-Encoding
* Content-Range response is "bytes x-y/z" not "x-y/z"
R=rsc
CC=golang-dev
https://golang.org/cl/4018041
Also adds some tests for Issue 900 which was the reason
the current URL parsing is broken. (the previous fix
was wrong)
R=rsc, adg, dangabrad, bradfitzwork
CC=golang-dev
https://golang.org/cl/3910042
In the case where r.Method == "POST", was
calling Printf with an argument but "" format string,
causing a spurious %!EXTRA(...) message.
Also escape string properly in HTML generation.
R=r
CC=golang-dev
https://golang.org/cl/3923043
New logging interface simplifies and generalizes.
1) Loggers now have only one output.
2) log.Stdout, Stderr, Crash and friends are gone.
Logging is now always to standard error by default.
3) log.Panic* replaces log.Crash*.
4) Exiting and panicking are not part of the logger's state; instead
the functions Exit* and Panic* simply call Exit or panic after
printing.
5) There is now one 'standard logger'. Instead of calling Stderr,
use Print etc. There are now triples, by analogy with fmt:
Print, Println, Printf
What was log.Stderr is now best represented by log.Println,
since there are now separate Print and Println functions
(and methods).
6) New functions SetOutput, SetFlags, and SetPrefix allow global
editing of the standard logger's properties. This is new
functionality. For instance, one can call
log.SetFlags(log.Lshortfile|log.Ltime|log.Lmicroseconds)
to get all logging output to show file name, line number, and
time stamp.
In short, for most purposes
log.Stderr -> log.Println or log.Print
log.Stderrf -> log.Printf
log.Crash -> log.Panicln or log.Panic
log.Crashf -> log.Panicf
log.Exit -> log.Exitln or log.Exit
log.Exitf -> log.Exitf (no change)
This has a slight breakage: since loggers now write only to one
output, existing calls to log.New() need to delete the second argument.
Also, custom loggers with exit or panic properties will need to be
reworked.
All package code updated to new interface.
The test has been reworked somewhat.
The old interface will be removed after the new release.
For now, its elements are marked 'deprecated' in their comments.
Fixes#1184.
R=rsc
CC=golang-dev
https://golang.org/cl/2419042
This is a common task, so it makes sense to have a helper to do it.
(App Engine doesn't like "Transfer-Encoding: chunked" for POST
bodies, which is the default for regular Post.)
R=rsc
CC=golang-dev
https://golang.org/cl/2113041
This changeset implements client certificate support in crypto/tls
for both handshake_server.go and handshake_client.go
The updated server implementation sends an empty CertificateAuthorities
field in the CertificateRequest, thus allowing clients to send any
certificates they wish. Likewise, the client code will only respond
with its certificate when the server requests a certificate with this
field empty.
R=agl, rsc, agl1
CC=golang-dev
https://golang.org/cl/1975042
Somewhat of a work-in-progress (in that MIME is a large spec), but this is
functional and enough for discussion and/or code review.
In addition to the unit tests, I've tested with curl and Chrome with
a variety of test files, making sure the digests of files are unaltered
when read via a multipart Part.
R=rsc, adg, dsymonds1, agl1
CC=golang-dev
https://golang.org/cl/1681049
This CL replaces my earlier https://golang.org/cl/1640044/show
in which Continue handling was explicit. Instead, this CL makes
it automatic. Reading from Body() is an implicit acknowledgement
that the request headers were fine and the body is wanted. In that
case, the 100 Continue response is written automatically when the
request continues the "Expect: 100-continue" header.
R=rsc, adg
CC=golang-dev
https://golang.org/cl/1610042
