Skip to content

Instantly share code, notes, and snippets.

@gzuidhof

gzuidhof/net.http.ts

Created March 8, 2022 00:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gzuidhof/7e192a2f33d8a4f5bde5b77fb2c5048c to your computer and use it in GitHub Desktop.
Save gzuidhof/7e192a2f33d8a4f5bde5b77fb2c5048c to your computer and use it in GitHub Desktop.
Download ZIP
Tygo Go stdlib output examples
Raw
net.http.ts
// "net/http" package tygo output
// Code generated by tygo. DO NOT EDIT.
//////////
// source: client.go
/**
* A Client is an HTTP client. Its zero value (DefaultClient) is a
* usable client that uses DefaultTransport.
* The Client's Transport typically has internal state (cached TCP
* connections), so Clients should be reused instead of created as
* needed. Clients are safe for concurrent use by multiple goroutines.
* A Client is higher-level than a RoundTripper (such as Transport)
* and additionally handles HTTP details such as cookies and
* redirects.
* When following redirects, the Client will forward all headers set on the
* initial Request except:
* • when forwarding sensitive headers like "Authorization",
* "WWW-Authenticate", and "Cookie" to untrusted targets.
* These headers will be ignored when following a redirect to a domain
* that is not a subdomain match or exact match of the initial domain.
* For example, a redirect from "foo.com" to either "foo.com" or "sub.foo.com"
* will forward the sensitive headers, but a redirect to "bar.com" will not.
* • when forwarding the "Cookie" header with a non-nil cookie Jar.
* Since each redirect may mutate the state of the cookie jar,
* a redirect may possibly alter a cookie set in the initial request.
* When forwarding the "Cookie" header, any mutated cookies will be omitted,
* with the expectation that the Jar will insert those mutated cookies
* with the updated values (assuming the origin matches).
* If Jar is nil, the initial cookies are forwarded without change.
*/
export interface Client {
/**
* Transport specifies the mechanism by which individual
* HTTP requests are made.
* If nil, DefaultTransport is used.
*/
Transport: RoundTripper;
/**
* CheckRedirect specifies the policy for handling redirects.
* If CheckRedirect is not nil, the client calls it before
* following an HTTP redirect. The arguments req and via are
* the upcoming request and the requests made already, oldest
* first. If CheckRedirect returns an error, the Client's Get
* method returns both the previous Response (with its Body
* closed) and CheckRedirect's error (wrapped in a url.Error)
* instead of issuing the Request req.
* As a special case, if CheckRedirect returns ErrUseLastResponse,
* then the most recent response is returned with its body
* unclosed, along with a nil error.
* If CheckRedirect is nil, the Client uses its default policy,
* which is to stop after 10 consecutive requests.
*/
CheckRedirect: any;
/**
* Jar specifies the cookie jar.
* The Jar is used to insert relevant cookies into every
* outbound Request and is updated with the cookie values
* of every inbound Response. The Jar is consulted for every
* redirect that the Client follows.
* If Jar is nil, cookies are only sent if they are explicitly
* set on the Request.
*/
Jar: CookieJar;
/**
* Timeout specifies a time limit for requests made by this
* Client. The timeout includes connection time, any
* redirects, and reading the response body. The timer remains
* running after Get, Head, Post, or Do return and will
* interrupt reading of the Response.Body.
* A Timeout of zero means no timeout.
* The Client cancels requests to the underlying Transport
* as if the Request's Context ended.
* For compatibility, the Client will also use the deprecated
* CancelRequest method on Transport if found. New
* RoundTripper implementations should use the Request's Context
* for cancellation instead of implementing CancelRequest.
*/
Timeout: number /* time in nanoseconds (time.Duration) */;
}
/**
* RoundTripper is an interface representing the ability to execute a
* single HTTP transaction, obtaining the Response for a given Request.
* A RoundTripper must be safe for concurrent use by multiple
* goroutines.
*/
export type RoundTripper = any;
/**
* The first way, used only for RoundTripper
* implementations written before Go 1.5 or Go 1.6.
*/
/**
* Close the previous response's body. But
* read at least some of the body so if it's
* small the underlying TCP connection will be
* re-used. No need to check for errors: if it
* fails, the Transport won't reuse it anyway.
*/
/**
* cancelTimerBody is an io.ReadCloser that wraps rc with two features:
* 1) On Read error or close, the stop func is called.
* 2) On Read failure, if reqDidTimeout is true, the error is wrapped and
* marked as net.Error that hit its timeout.
*/
//////////
// source: cookie.go
/**
* A Cookie represents an HTTP cookie as sent in the Set-Cookie header of an
* HTTP response or the Cookie header of an HTTP request.
* See https://tools.ietf.org/html/rfc6265 for details.
*/
export interface Cookie {
Name: string;
Value: string;
Path: string; // optional
Domain: string; // optional
Expires: any /* time.Time */; // optional
RawExpires: string; // for reading cookies only
/**
* MaxAge=0 means no 'Max-Age' attribute specified.
* MaxAge<0 means delete cookie now, equivalently 'Max-Age: 0'
* MaxAge>0 means Max-Age attribute present and given in seconds
*/
MaxAge: number /* int */;
Secure: boolean;
HttpOnly: boolean;
SameSite: SameSite;
Raw: string;
Unparsed: string[]; // Raw text of unparsed attribute-value pairs
}
/**
* SameSite allows a server to define a cookie attribute making it impossible for
* the browser to send this cookie along with cross-site requests. The main
* goal is to mitigate the risk of cross-origin information leakage, and provide
* some protection against cross-site request forgery attacks.
* See https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00 for details.
*/
export type SameSite = number /* int */;
export const SameSiteDefaultMode: SameSite = 1;
export const SameSiteLaxMode: SameSite = 2;
export const SameSiteStrictMode: SameSite = 3;
export const SameSiteNoneMode: SameSite = 4;
/**
* extraCookieLength derived from typical length of cookie attributes
* see RFC 6265 Sec 4.1.
*/
//////////
// source: filetransport.go
/**
* fileTransport implements RoundTripper for the 'file' protocol.
*/
/**
* populateResponse is a ResponseWriter that populates the *Response
* in res, and writes its body to a pipe connected to the response
* body. Once writes begin or finish() is called, the response is sent
* on ch.
*/
//////////
// source: fs.go
/**
* A Dir implements FileSystem using the native file system restricted to a
* specific directory tree.
* While the FileSystem.Open method takes '/'-separated paths, a Dir's string
* value is a filename on the native file system, not a URL, so it is separated
* by filepath.Separator, which isn't necessarily '/'.
* Note that Dir could expose sensitive files and directories. Dir will follow
* symlinks pointing out of the directory tree, which can be especially dangerous
* if serving from a directory in which users are able to create arbitrary symlinks.
* Dir will also allow access to files and directories starting with a period,
* which could expose sensitive directories like .git or sensitive files like
* .htpasswd. To exclude files with a leading period, remove the files/directories
* from the server or create a custom FileSystem implementation.
* An empty Dir is treated as ".".
*/
export type Dir = string;
/**
* A FileSystem implements access to a collection of named files.
* The elements in a file path are separated by slash ('/', U+002F)
* characters, regardless of host operating system convention.
* See the FileServer function to convert a FileSystem to a Handler.
* This interface predates the fs.FS interface, which can be used instead:
* the FS adapter function converts an fs.FS to a FileSystem.
*/
export type FileSystem = any;
/**
* A File is returned by a FileSystem's Open method and can be
* served by the FileServer implementation.
* The methods should behave the same as those on an *os.File.
*/
export type File = any;
/**
* condResult is the result of an HTTP request precondition check.
* See https://tools.ietf.org/html/rfc7232 section 3.
*/
/**
* httpRange specifies the byte range to be sent to the client.
*/
/**
* countingWriter counts how many bytes have been written to it.
*/
//////////
// source: h2_bundle.go
/**
* ClientConnPool manages a pool of HTTP/2 client connections.
*/
/**
* clientConnPoolIdleCloser is the interface implemented by ClientConnPool
* implementations which can close their idle connections.
*/
/**
* TODO: use singleflight for dialing and addConnCalls?
*/
/**
* dialCall is an in-flight Transport dial call to a host.
*/
/**
* noDialClientConnPool is an implementation of http2.ClientConnPool
* which never dials. We let the HTTP/1.1 client dial and use its TLS
* connection instead.
*/
/**
* dataBuffer is an io.ReadWriter backed by a list of data chunks.
* Each dataBuffer is used to read DATA frames on a single stream.
* The buffer is divided into chunks so the server can limit the
* total memory used by a single connection without limiting the
* request body size on any single stream.
*/
/**
* An ErrCode is an unsigned 32-bit error code as defined in the HTTP/2 spec.
*/
/**
* ConnectionError is an error that results in the termination of the
* entire connection.
*/
/**
* StreamError is an error that only affects one stream within an
* HTTP/2 connection.
*/
/**
* 6.9.1 The Flow Control Window
* "If a sender receives a WINDOW_UPDATE that causes a flow control
* window to exceed this maximum it MUST terminate either the stream
* or the connection, as appropriate. For streams, [...]; for the
* connection, a GOAWAY frame with a FLOW_CONTROL_ERROR code."
*/
/**
* connError represents an HTTP/2 ConnectionError error code, along
* with a string (for debugging) explaining why.
* Errors of this type are only returned by the frame parser functions
* and converted into ConnectionError(Code), after stashing away
* the Reason into the Framer's errDetail field, accessible via
* the (*Framer).ErrorDetail method.
*/
/**
* flow is the flow control window's size.
*/
/**
* A FrameType is a registered frame type as defined in
* http://http2.github.io/http2-spec/#rfc.section.11.2
*/
/**
* Flags is a bitmask of HTTP/2 flags.
* The meaning of flags varies depending on the frame type.
*/
/**
* a frameParser parses a frame given its FrameHeader and payload
* bytes. The length of payload will always equal fh.Length (which
* might be 0).
*/
/**
* A FrameHeader is the 9 byte header of all HTTP/2 frames.
* See http://http2.github.io/http2-spec/#FrameHeader
*/
/**
* A Frame is the base interface implemented by all frame types.
* Callers will generally type-assert the specific frame type:
* *HeadersFrame, *SettingsFrame, *WindowUpdateFrame, etc.
* Frames are only valid until the next call to Framer.ReadFrame.
*/
/**
* A Framer reads and writes Frames.
*/
/**
* A DataFrame conveys arbitrary, variable-length sequences of octets
* associated with a stream.
* See http://http2.github.io/http2-spec/#rfc.section.6.1
*/
/**
* A SettingsFrame conveys configuration parameters that affect how
* endpoints communicate, such as preferences and constraints on peer
* behavior.
* See http://http2.github.io/http2-spec/#SETTINGS
*/
/**
* A PingFrame is a mechanism for measuring a minimal round trip time
* from the sender, as well as determining whether an idle connection
* is still functional.
* See http://http2.github.io/http2-spec/#rfc.section.6.7
*/
/**
* A GoAwayFrame informs the remote peer to stop creating streams on this connection.
* See http://http2.github.io/http2-spec/#rfc.section.6.8
*/
/**
* An UnknownFrame is the frame type returned when the frame type is unknown
* or no specific frame type parser exists.
*/
/**
* A WindowUpdateFrame is used to implement flow control.
* See http://http2.github.io/http2-spec/#rfc.section.6.9
*/
/**
* A HeadersFrame is used to open a stream and additionally carries a
* header block fragment.
*/
/**
* HeadersFrameParam are the parameters for writing a HEADERS frame.
*/
/**
* A PriorityFrame specifies the sender-advised priority of a stream.
* See http://http2.github.io/http2-spec/#rfc.section.6.3
*/
/**
* PriorityParam are the stream prioritzation parameters.
*/
/**
* A RSTStreamFrame allows for abnormal termination of a stream.
* See http://http2.github.io/http2-spec/#rfc.section.6.4
*/
/**
* A ContinuationFrame is used to continue a sequence of header block fragments.
* See http://http2.github.io/http2-spec/#rfc.section.6.10
*/
/**
* A PushPromiseFrame is used to initiate a server stream.
* See http://http2.github.io/http2-spec/#rfc.section.6.6
*/
/**
* PushPromiseParam are the parameters for writing a PUSH_PROMISE frame.
*/
/**
* A MetaHeadersFrame is the representation of one HEADERS frame and
* zero or more contiguous CONTINUATION frames and the decoding of
* their HPACK-encoded contents.
* This type of frame does not appear on the wire and is only returned
* by the Framer when Framer.ReadMetaHeaders is set.
*/
/**
* Setting is a setting parameter: which setting it is, and its value.
*/
/**
* A SettingID is an HTTP/2 setting as defined in
* http://http2.github.io/http2-spec/#iana-settings
*/
/**
* from pkg io
*/
/**
* A gate lets two goroutines coordinate their activities.
*/
/**
* A closeWaiter is like a sync.WaitGroup but only goes 1 to 0 (open to closed).
*/
/**
* bufferedWriter is a buffered writer that writes to w.
* Its buffered writer is lazily allocated as needed, to minimize
* idle memory usage with many connections.
*/
/**
* bufWriterPoolBufferSize is the size of bufio.Writer's
* buffers created using bufWriterPool.
* TODO: pick a less arbitrary value? this is a bit under
* (3 x typical 1500 byte MTU) at least. Other than that,
* not much thought went into it.
*/
/**
* incomparable is a zero-width, non-comparable type. Adding it to a struct
* makes that struct also non-comparable, and generally doesn't add
* any size (as long as it's first).
*/
/**
* pipe is a goroutine-safe io.Reader/io.Writer pair. It's like
* io.Pipe except there are no PipeReader/PipeWriter halves, and the
* underlying buffer is an interface. (io.Pipe is always unbuffered)
*/
/**
* Server is an HTTP/2 server.
*/
/**
* ServeConnOpts are options for the Server.ServeConn method.
*/
/**
* http2's count is in a slightly different unit and includes 32 bytes per pair.
* So, take the net/http.Server value and pad it up a bit, assuming 10 headers.
*/
/**
* stream represents a stream. This is the minimal metadata needed by
* the serve goroutine. Most of the actual stream state is owned by
* the http.Handler's goroutine in the responseWriter. Because the
* responseWriter's responseWriterState is recycled at the end of a
* handler, this struct intentionally has no pointer to the
* *responseWriter{,State} itself, as the Handler ending nils out the
* responseWriter's state field.
*/
export const WSAECONNABORTED = 10053;
export const WSAECONNRESET = 10054;
/**
* frameWriteResult is the message passed from writeFrameAsync to the serve goroutine.
*/
/**
* 10.5.1 Limits on Header Block Size:
* .. "A server that receives a larger header block than it is
* willing to handle can send an HTTP 431 (Request Header Fields Too
* Large) status code"
*/
/**
* A bodyReadMsg tells the server loop that the http.Handler read n
* bytes of the DATA from the client on the given stream.
*/
/**
* "The legal range for the increment to the flow control
* window is 1 to 2^31-1 (2,147,483,647) octets."
* A Go Read call on 64-bit machines could in theory read
* a larger Read than this. Very unlikely, but we handle it here
* rather than elsewhere for now.
*/
/**
* requestBody is the Handler's Request.Body type.
* Read and Close may be called concurrently.
*/
/**
* responseWriter is the http.ResponseWriter implementation. It's
* intentionally small (1 pointer wide) to minimize garbage. The
* responseWriterState pointer inside is zeroed at the end of a
* request (in handlerDone) and calls on the responseWriter thereafter
* simply crash (caller's mistake), but the much larger responseWriterState
* and buffers are reused between multiple requests.
*/
/**
* TrailerPrefix is a magic prefix for ResponseWriter.Header map keys
* that, if present, signals that the map entry is actually for
* the response trailers, and not the response headers. The prefix
* is stripped after the ServeHTTP call finishes and the values are
* sent in the trailers.
* This mechanism is intended only for trailers that are not known
* prior to the headers being written. If the set of trailers is fixed
* or known before the header is written, the normal Go trailers mechanism
* is preferred:
* https://golang.org/pkg/net/http/#ResponseWriter
* https://golang.org/pkg/net/http/#example_ResponseWriter_trailers
*/
export type I = any;
/**
* Transport is an HTTP/2 Transport.
* A Transport internally caches connections to servers. It is safe
* for concurrent use by multiple goroutines.
*/
/**
* ClientConn is the state of a single HTTP/2 client connection to an
* HTTP/2 server.
*/
/**
* clientStream is the state for a single HTTP/2 stream. One of these
* is created for each Transport.RoundTrip call.
*/
/**
* noCachedConnError is the concrete type of ErrNoCachedConn, which
* needs to be detected by net/http regardless of whether it's its
* bundled version (in h2_bundle.go with a rewritten type name) or
* from a user's x/net/http2. As such, as it has a unique method name
* (IsHTTP2NoCachedConnError) that net/http sniffs for via func
* isNoCachedConnError.
*/
/**
* RoundTripOpt are options for the Transport.RoundTripOpt method.
*/
/**
* clientConnIdleState describes the suitability of a client
* connection to initiate a new RoundTrip request.
*/
/**
* clientConnReadLoop is the state owned by the clientConn's frame-reading readLoop.
*/
/**
* GoAwayError is returned by the Transport when the server closes the
* TCP connection after sending a GOAWAY frame.
*/
/**
* transportResponseBody is the concrete type of Transport.RoundTrip's
* Response.Body. It is an io.ReadCloser. On Read, it reads from cs.body.
* On Close it sends RST_STREAM if EOF wasn't already seen.
*/
/**
* gzipReader wraps a response body so it can lazily
* call gzip.NewReader on the first call to Read
*/
/**
* bodyWriterState encapsulates various state around the Transport's writing
* of the request body, particularly regarding doing delayed writes of the body
* when the request contains "Expect: 100-continue".
*/
/**
* Arm the timer with a very large duration, which we'll
* intentionally lower later. It has to be large now because
* we need a handle to it before writing the headers, but the
* s.delay value is defined to not start until after the
* request headers were written.
*/
/**
* noDialH2RoundTripper is a RoundTripper which only tries to complete the request
* if there's already has a cached connection to the host.
* (The field is exported so it can be accessed via reflect from net/http; tested
* by TestNoDialH2RoundTripperType)
*/
/**
* writeFramer is implemented by any type that is used to write frames.
*/
/**
* writeContext is the interface needed by the various frame writer
* types below. All the writeFrame methods below are scheduled via the
* frame writing scheduler (see writeScheduler in writesched.go).
* This interface is implemented by *serverConn.
* TODO: decide whether to a) use this in the client code (which didn't
* end up using this yet, because it has a simpler design, not
* currently implementing priorities), or b) delete this and
* make the server code a bit more concrete.
*/
/**
* handlerPanicRST is the message sent from handler goroutines when
* the handler panics.
*/
/**
* For now we're lazy and just pick the minimum MAX_FRAME_SIZE
* that all peers must support (16KB). Later we could care
* more and send larger frames if the peer advertised it, but
* there's little point. Most headers are small anyway (so we
* generally won't have CONTINUATION frames), and extra frames
* only waste 9 bytes anyway.
*/
/**
* writeResHeaders is a request to write a HEADERS and 0+ CONTINUATION frames
* for HTTP response headers or trailers from a server handler.
*/
/**
* writePushPromise is a request to write a PUSH_PROMISE and 0+ CONTINUATION frames.
*/
/**
* WriteScheduler is the interface implemented by HTTP/2 write schedulers.
* Methods are never called concurrently.
*/
/**
* OpenStreamOptions specifies extra options for WriteScheduler.OpenStream.
*/
/**
* FrameWriteRequest is a request to write a frame.
*/
/**
* writeQueue is used by implementations of WriteScheduler.
*/
/**
* RFC 7540, Section 5.3.5: the default weight is 16.
*/
/**
* PriorityWriteSchedulerConfig configures a priorityWriteScheduler.
*/
/**
* priorityNode is a node in an HTTP/2 priority tree.
* Each node is associated with a single stream ID.
* See RFC 7540, Section 5.3.
*/
//////////
// source: header.go
/**
* A Header represents the key-value pairs in an HTTP header.
* The keys should be in canonical form, as returned by
* CanonicalHeaderKey.
*/
export type Header = { [key: string]: string[]};
/**
* stringWriter implements WriteString on a Writer.
*/
/**
* A headerSorter implements sort.Interface by sorting a []keyValues
* by key. It's used as a pointer, so it can fit in a sort.Interface
* interface value without allocation.
*/
//////////
// source: http.go
/**
* incomparable is a zero-width, non-comparable type. Adding it to a struct
* makes that struct also non-comparable, and generally doesn't add
* any size (as long as it's first).
*/
/**
* maxInt64 is the effective "infinite" value for the Server and
* Transport's byte-limiting readers.
*/
/**
* contextKey is a value for use with context.WithValue. It's used as
* a pointer so it fits in an interface{} without allocation.
*/
/**
* PushOptions describes options for Pusher.Push.
*/
export interface PushOptions {
/**
* Method specifies the HTTP method for the promised request.
* If set, it must be "GET" or "HEAD". Empty means "GET".
*/
Method: string;
/**
* Header specifies additional promised request headers. This cannot
* include HTTP/2 pseudo header fields like ":path" and ":scheme",
* which will be added automatically.
*/
Header: Header;
}
/**
* Pusher is the interface implemented by ResponseWriters that support
* HTTP/2 server push. For more background, see
* https://tools.ietf.org/html/rfc7540#section-8.2.
*/
export type Pusher = any;
//////////
// source: jar.go
/**
* A CookieJar manages storage and use of cookies in HTTP requests.
* Implementations of CookieJar must be safe for concurrent use by multiple
* goroutines.
* The net/http/cookiejar package provides a CookieJar implementation.
*/
export type CookieJar = any;
//////////
// source: method.go
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodGet = "GET";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodHead = "HEAD";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodPost = "POST";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodPut = "PUT";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodPatch = "PATCH"; // RFC 5789
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodDelete = "DELETE";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodConnect = "CONNECT";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodOptions = "OPTIONS";
/**
* Common HTTP methods.
* Unless otherwise noted, these are defined in RFC 7231 section 4.3.
*/
export const MethodTrace = "TRACE";
//////////
// source: request.go
/**
* ProtocolError represents an HTTP protocol error.
* Deprecated: Not all errors in the http package related to protocol errors
* are of type ProtocolError.
*/
export interface ProtocolError {
ErrorString: string;
}
/**
* A Request represents an HTTP request received by a server
* or to be sent by a client.
* The field semantics differ slightly between client and server
* usage. In addition to the notes on the fields below, see the
* documentation for Request.Write and RoundTripper.
*/
export interface Request {
/**
* Method specifies the HTTP method (GET, POST, PUT, etc.).
* For client requests, an empty string means GET.
* Go's HTTP client does not support sending a request with
* the CONNECT method. See the documentation on Transport for
* details.
*/
Method: string;
/**
* URL specifies either the URI being requested (for server
* requests) or the URL to access (for client requests).
* For server requests, the URL is parsed from the URI
* supplied on the Request-Line as stored in RequestURI. For
* most requests, fields other than Path and RawQuery will be
* empty. (See RFC 7230, Section 5.3)
* For client requests, the URL's Host specifies the server to
* connect to, while the Request's Host field optionally
* specifies the Host header value to send in the HTTP
* request.
*/
URL?: any /* url.URL */;
/**
* The protocol version for incoming server requests.
* For client requests, these fields are ignored. The HTTP
* client code always uses either HTTP/1.1 or HTTP/2.
* See the docs on Transport for details.
*/
Proto: string; // "HTTP/1.0"
ProtoMajor: number /* int */; // 1
ProtoMinor: number /* int */; // 0
/**
* Header contains the request header fields either received
* by the server or to be sent by the client.
* If a server received a request with header lines,
* Host: example.com
* accept-encoding: gzip, deflate
* Accept-Language: en-us
* fOO: Bar
* foo: two
* then
* Header = map[string][]string{
* "Accept-Encoding": {"gzip, deflate"},
* "Accept-Language": {"en-us"},
* "Foo": {"Bar", "two"},
* }
* For incoming requests, the Host header is promoted to the
* Request.Host field and removed from the Header map.
* HTTP defines that header names are case-insensitive. The
* request parser implements this by using CanonicalHeaderKey,
* making the first character and any characters following a
* hyphen uppercase and the rest lowercase.
* For client requests, certain headers such as Content-Length
* and Connection are automatically written when needed and
* values in Header may be ignored. See the documentation
* for the Request.Write method.
*/
Header: Header;
/**
* Body is the request's body.
* For client requests, a nil body means the request has no
* body, such as a GET request. The HTTP Client's Transport
* is responsible for calling the Close method.
* For server requests, the Request Body is always non-nil
* but will return EOF immediately when no body is present.
* The Server will close the request body. The ServeHTTP
* Handler does not need to.
* Body must allow Read to be called concurrently with Close.
* In particular, calling Close should unblock a Read waiting
* for input.
*/
Body: any /* io.ReadCloser */;
/**
* GetBody defines an optional func to return a new copy of
* Body. It is used for client requests when a redirect requires
* reading the body more than once. Use of GetBody still
* requires setting Body.
* For server requests, it is unused.
*/
GetBody: any;
/**
* ContentLength records the length of the associated content.
* The value -1 indicates that the length is unknown.
* Values >= 0 indicate that the given number of bytes may
* be read from Body.
* For client requests, a value of 0 with a non-nil Body is
* also treated as unknown.
*/
ContentLength: number /* int64 */;
/**
* TransferEncoding lists the transfer encodings from outermost to
* innermost. An empty list denotes the "identity" encoding.
* TransferEncoding can usually be ignored; chunked encoding is
* automatically added and removed as necessary when sending and
* receiving requests.
*/
TransferEncoding: string[];
/**
* Close indicates whether to close the connection after
* replying to this request (for servers) or after sending this
* request and reading its response (for clients).
* For server requests, the HTTP server handles this automatically
* and this field is not needed by Handlers.
* For client requests, setting this field prevents re-use of
* TCP connections between requests to the same hosts, as if
* Transport.DisableKeepAlives were set.
*/
Close: boolean;
/**
* For server requests, Host specifies the host on which the
* URL is sought. For HTTP/1 (per RFC 7230, section 5.4), this
* is either the value of the "Host" header or the host name
* given in the URL itself. For HTTP/2, it is the value of the
* ":authority" pseudo-header field.
* It may be of the form "host:port". For international domain
* names, Host may be in Punycode or Unicode form. Use
* golang.org/x/net/idna to convert it to either format if
* needed.
* To prevent DNS rebinding attacks, server Handlers should
* validate that the Host header has a value for which the
* Handler considers itself authoritative. The included
* ServeMux supports patterns registered to particular host
* names and thus protects its registered Handlers.
* For client requests, Host optionally overrides the Host
* header to send. If empty, the Request.Write method uses
* the value of URL.Host. Host may contain an international
* domain name.
*/
Host: string;
/**
* Form contains the parsed form data, including both the URL
* field's query parameters and the PATCH, POST, or PUT form data.
* This field is only available after ParseForm is called.
* The HTTP client ignores Form and uses Body instead.
*/
Form: any /* url.Values */;
/**
* PostForm contains the parsed form data from PATCH, POST
* or PUT body parameters.
* This field is only available after ParseForm is called.
* The HTTP client ignores PostForm and uses Body instead.
*/
PostForm: any /* url.Values */;
/**
* MultipartForm is the parsed multipart form, including file uploads.
* This field is only available after ParseMultipartForm is called.
* The HTTP client ignores MultipartForm and uses Body instead.
*/
MultipartForm?: any /* multipart.Form */;
/**
* Trailer specifies additional headers that are sent after the request
* body.
* For server requests, the Trailer map initially contains only the
* trailer keys, with nil values. (The client declares which trailers it
* will later send.) While the handler is reading from Body, it must
* not reference Trailer. After reading from Body returns EOF, Trailer
* can be read again and will contain non-nil values, if they were sent
* by the client.
* For client requests, Trailer must be initialized to a map containing
* the trailer keys to later send. The values may be nil or their final
* values. The ContentLength must be 0 or -1, to send a chunked request.
* After the HTTP request is sent the map values can be updated while
* the request body is read. Once the body returns EOF, the caller must
* not mutate Trailer.
* Few HTTP clients, servers, or proxies support HTTP trailers.
*/
Trailer: Header;
/**
* RemoteAddr allows HTTP servers and other software to record
* the network address that sent the request, usually for
* logging. This field is not filled in by ReadRequest and
* has no defined format. The HTTP server in this package
* sets RemoteAddr to an "IP:port" address before invoking a
* handler.
* This field is ignored by the HTTP client.
*/
RemoteAddr: string;
/**
* RequestURI is the unmodified request-target of the
* Request-Line (RFC 7230, Section 3.1.1) as sent by the client
* to a server. Usually the URL field should be used instead.
* It is an error to set this field in an HTTP client request.
*/
RequestURI: string;
/**
* TLS allows HTTP servers and other software to record
* information about the TLS connection on which the request
* was received. This field is not filled in by ReadRequest.
* The HTTP server in this package sets the field for
* TLS-enabled connections before invoking a handler;
* otherwise it leaves the field nil.
* This field is ignored by the HTTP client.
*/
TLS?: any /* tls.ConnectionState */;
/**
* Cancel is an optional channel whose closure indicates that the client
* request should be regarded as canceled. Not all implementations of
* RoundTripper may support Cancel.
* For server requests, this field is not applicable.
* Deprecated: Set the Request's context with NewRequestWithContext
* instead. If a Request's Cancel field and context are both
* set, it is undefined whether Cancel is respected.
*/
Cancel: any;
/**
* Response is the redirect response which caused this request
* to be created. This field is only populated during client
* redirects.
*/
Response?: Response;
}
/**
* NOTE: This is not intended to reflect the actual Go version being used.
* It was changed at the time of Go 1.1 release because the former User-Agent
* had ended up blocked by some intrusion detection systems.
* See https://codereview.appspot.com/7532043.
*/
/**
* requestBodyReadError wraps an error from (*Request).write to indicate
* that the error came from a Read call on the Request.Body.
* This error type should not escape the net/http package to users.
*/
export const Big = 1000000; // arbitrary upper bound
/**
* The server code and client code both use
* maxBytesReader. This "requestTooLarge" check is
* only used by the server code. To prevent binaries
* which only using the HTTP Client code (such as
* cmd/go) from also linking in the HTTP server, don't
* use a static type assertion to the server
* "*response" type. Check this interface instead:
*/
//////////
// source: response.go
/**
* Response represents the response from an HTTP request.
* The Client and Transport return Responses from servers once
* the response headers have been received. The response body
* is streamed on demand as the Body field is read.
*/
export interface Response {
Status: string; // e.g. "200 OK"
StatusCode: number /* int */; // e.g. 200
Proto: string; // e.g. "HTTP/1.0"
ProtoMajor: number /* int */; // e.g. 1
ProtoMinor: number /* int */; // e.g. 0
/**
* Header maps header keys to values. If the response had multiple
* headers with the same key, they may be concatenated, with comma
* delimiters. (RFC 7230, section 3.2.2 requires that multiple headers
* be semantically equivalent to a comma-delimited sequence.) When
* Header values are duplicated by other fields in this struct (e.g.,
* ContentLength, TransferEncoding, Trailer), the field values are
* authoritative.
* Keys in the map are canonicalized (see CanonicalHeaderKey).
*/
Header: Header;
/**
* Body represents the response body.
* The response body is streamed on demand as the Body field
* is read. If the network connection fails or the server
* terminates the response, Body.Read calls return an error.
* The http Client and Transport guarantee that Body is always
* non-nil, even on responses without a body or responses with
* a zero-length body. It is the caller's responsibility to
* close Body. The default HTTP client's Transport may not
* reuse HTTP/1.x "keep-alive" TCP connections if the Body is
* not read to completion and closed.
* The Body is automatically dechunked if the server replied
* with a "chunked" Transfer-Encoding.
* As of Go 1.12, the Body will also implement io.Writer
* on a successful "101 Switching Protocols" response,
* as used by WebSockets and HTTP/2's "h2c" mode.
*/
Body: any /* io.ReadCloser */;
/**
* ContentLength records the length of the associated content. The
* value -1 indicates that the length is unknown. Unless Request.Method
* is "HEAD", values >= 0 indicate that the given number of bytes may
* be read from Body.
*/
ContentLength: number /* int64 */;
/**
* Contains transfer encodings from outer-most to inner-most. Value is
* nil, means that "identity" encoding is used.
*/
TransferEncoding: string[];
/**
* Close records whether the header directed that the connection be
* closed after reading Body. The value is advice for clients: neither
* ReadResponse nor Response.Write ever closes a connection.
*/
Close: boolean;
/**
* Uncompressed reports whether the response was sent compressed but
* was decompressed by the http package. When true, reading from
* Body yields the uncompressed content instead of the compressed
* content actually set from the server, ContentLength is set to -1,
* and the "Content-Length" and "Content-Encoding" fields are deleted
* from the responseHeader. To get the original response from
* the server, set Transport.DisableCompression to true.
*/
Uncompressed: boolean;
/**
* Trailer maps trailer keys to values in the same
* format as Header.
* The Trailer initially contains only nil values, one for
* each key specified in the server's "Trailer" header
* value. Those values are not added to Header.
* Trailer must not be accessed concurrently with Read calls
* on the Body.
* After Body.Read has returned io.EOF, Trailer will contain
* any trailer values sent by the server.
*/
Trailer: Header;
/**
* Request is the request that was sent to obtain this Response.
* Request's Body is nil (having already been consumed).
* This is only populated for Client requests.
*/
Request?: Request;
/**
* TLS contains information about the TLS connection on which the
* response was received. It is nil for unencrypted responses.
* The pointer is shared between responses and should not be
* modified.
*/
TLS?: any /* tls.ConnectionState */;
}
//////////
// source: server.go
/**
* A Handler responds to an HTTP request.
* ServeHTTP should write reply headers and data to the ResponseWriter
* and then return. Returning signals that the request is finished; it
* is not valid to use the ResponseWriter or read from the
* Request.Body after or concurrently with the completion of the
* ServeHTTP call.
* Depending on the HTTP client software, HTTP protocol version, and
* any intermediaries between the client and the Go server, it may not
* be possible to read from the Request.Body after writing to the
* ResponseWriter. Cautious handlers should read the Request.Body
* first, and then reply.
* Except for reading the body, handlers should not modify the
* provided Request.
* If ServeHTTP panics, the server (the caller of ServeHTTP) assumes
* that the effect of the panic was isolated to the active request.
* It recovers the panic, logs a stack trace to the server error log,
* and either closes the network connection or sends an HTTP/2
* RST_STREAM, depending on the HTTP protocol. To abort a handler so
* the client sees an interrupted response but the server doesn't log
* an error, panic with the value ErrAbortHandler.
*/
export type Handler = any;
/**
* A ResponseWriter interface is used by an HTTP handler to
* construct an HTTP response.
* A ResponseWriter may not be used after the Handler.ServeHTTP method
* has returned.
*/
export type ResponseWriter = any;
/**
* The Flusher interface is implemented by ResponseWriters that allow
* an HTTP handler to flush buffered data to the client.
* The default HTTP/1.x and HTTP/2 ResponseWriter implementations
* support Flusher, but ResponseWriter wrappers may not. Handlers
* should always test for this ability at runtime.
* Note that even for ResponseWriters that support Flush,
* if the client is connected through an HTTP proxy,
* the buffered data may not reach the client until the response
* completes.
*/
export type Flusher = any;
/**
* The Hijacker interface is implemented by ResponseWriters that allow
* an HTTP handler to take over the connection.
* The default ResponseWriter for HTTP/1.x connections supports
* Hijacker, but HTTP/2 connections intentionally do not.
* ResponseWriter wrappers may also not support Hijacker. Handlers
* should always test for this ability at runtime.
*/
export type Hijacker = any;
/**
* The CloseNotifier interface is implemented by ResponseWriters which
* allow detecting when the underlying connection has gone away.
* This mechanism can be used to cancel long operations on the server
* if the client has disconnected before the response is ready.
* Deprecated: the CloseNotifier interface predates Go's context package.
* New code should use Request.Context instead.
*/
export type CloseNotifier = any;
/**
* A conn represents the server side of an HTTP connection.
*/
/**
* This should be >= 512 bytes for DetectContentType,
* but otherwise it's somewhat arbitrary.
*/
/**
* chunkWriter writes to a response's conn buffer, and is the writer
* wrapped by the response.w buffered writer.
* chunkWriter also is responsible for finalizing the Header, including
* conditionally setting the Content-Type and setting a Content-Length
* in cases where the handler's final output is smaller than the buffer
* size. It also conditionally adds chunk headers, when in chunking mode.
* See the comment above (*response).Write for the entire write flow.
*/
/**
* A response represents the server side of an HTTP response.
*/
/**
* TrailerPrefix is a magic prefix for ResponseWriter.Header map keys
* that, if present, signals that the map entry is actually for
* the response trailers, and not the response headers. The prefix
* is stripped after the ServeHTTP call finishes and the values are
* sent in the trailers.
* This mechanism is intended only for trailers that are not known
* prior to the headers being written. If the set of trailers is fixed
* or known before the header is written, the normal Go trailers mechanism
* is preferred:
* https://golang.org/pkg/net/http/#ResponseWriter
* https://golang.org/pkg/net/http/#example_ResponseWriter_trailers
*/
export const TrailerPrefix = "Trailer:";
/**
* writerOnly hides an io.Writer value's optional ReadFrom method
* from io.Copy.
*/
/**
* debugServerConnections controls whether all server connections are wrapped
* with a verbose logging wrapper.
*/
/**
* connReader is the io.Reader wrapper used by *conn. It combines a
* selectively-activated io.LimitedReader (to bound request header
* read sizes) with support for selectively keeping an io.Reader.Read
* call blocked in a background goroutine to wait for activity and
* trigger a CloseNotifier channel.
*/
/**
* DefaultMaxHeaderBytes is the maximum permitted size of the headers
* in an HTTP request.
* This can be overridden by setting Server.MaxHeaderBytes.
*/
export const DefaultMaxHeaderBytes = 1 << 20; // 1 MB
/**
* wrapper around io.ReadCloser which on first read, sends an
* HTTP/1.1 100 Continue header
*/
/**
* TimeFormat is the time format to use when generating times in HTTP
* headers. It is like time.RFC1123 but hard-codes GMT as the time
* zone. The time being formatted must be in UTC for Format to
* generate the correct format.
* For parsing this time format, see ParseTime.
*/
export const TimeFormat = "Mon, 02 Jan 2006 15:04:05 GMT";
/**
* maxPostHandlerReadBytes is the max number of Request.Body bytes not
* consumed by a handler that the server will read from the client
* in order to keep a connection alive. If there are more bytes than
* this then the server to be paranoid instead sends a "Connection:
* close" response.
* This number is approximately what a typical machine's TCP buffer
* size is anyway. (if we have the bytes on the machine, we might as
* well read them)
*/
/**
* extraHeader is the set of headers sometimes added by chunkWriter.writeHeader.
* This type is used to avoid extra allocations from cloning and/or populating
* the response Header map and all its 1-element slices.
*/
/**
* rstAvoidanceDelay is the amount of time we sleep after closing the
* write side of a TCP connection before closing the entire socket.
* By sleeping, we increase the chances that the client sees our FIN
* and processes its final data before they process the subsequent RST
* from closing a connection with known unread data.
* This RST seems to occur mostly on BSD systems. (And Windows?)
* This timeout is somewhat arbitrary (~latency around the planet).
*/
/**
* statusError is an error used to respond to a request with an HTTP status.
* The text should be plain text without user info or other embedded errors.
*/
/**
* Their HTTP client may or may not be
* able to read this if we're
* responding to them and hanging up
* while they're still writing their
* request. Undefined behavior.
*/
/**
* The HandlerFunc type is an adapter to allow the use of
* ordinary functions as HTTP handlers. If f is a function
* with the appropriate signature, HandlerFunc(f) is a
* Handler that calls f.
*/
export type HandlerFunc = any;
/**
* Redirect to a fixed URL
*/
/**
* ServeMux is an HTTP request multiplexer.
* It matches the URL of each incoming request against a list of registered
* patterns and calls the handler for the pattern that
* most closely matches the URL.
* Patterns name fixed, rooted paths, like "/favicon.ico",
* or rooted subtrees, like "/images/" (note the trailing slash).
* Longer patterns take precedence over shorter ones, so that
* if there are handlers registered for both "/images/"
* and "/images/thumbnails/", the latter handler will be
* called for paths beginning "/images/thumbnails/" and the
* former will receive requests for any other paths in the
* "/images/" subtree.
* Note that since a pattern ending in a slash names a rooted subtree,
* the pattern "/" matches all paths not matched by other registered
* patterns, not just the URL with Path == "/".
* If a subtree has been registered and a request is received naming the
* subtree root without its trailing slash, ServeMux redirects that
* request to the subtree root (adding the trailing slash). This behavior can
* be overridden with a separate registration for the path without
* the trailing slash. For example, registering "/images/" causes ServeMux
* to redirect a request for "/images" to "/images/", unless "/images" has
* been registered separately.
* Patterns may optionally begin with a host name, restricting matches to
* URLs on that host only. Host-specific patterns take precedence over
* general patterns, so that a handler might register for the two patterns
* "/codesearch" and "codesearch.google.com/" without also taking over
* requests for "http://www.google.com/".
* ServeMux also takes care of sanitizing the URL request path and the Host
* header, stripping the port number and redirecting any request containing . or
* .. elements or repeated slashes to an equivalent, cleaner URL.
*/
export interface ServeMux {
}
/**
* A Server defines parameters for running an HTTP server.
* The zero value for Server is a valid configuration.
*/
export interface Server {
/**
* Addr optionally specifies the TCP address for the server to listen on,
* in the form "host:port". If empty, ":http" (port 80) is used.
* The service names are defined in RFC 6335 and assigned by IANA.
* See net.Dial for details of the address format.
*/
Addr: string;
Handler: Handler; // handler to invoke, http.DefaultServeMux if nil
/**
* TLSConfig optionally provides a TLS configuration for use
* by ServeTLS and ListenAndServeTLS. Note that this value is
* cloned by ServeTLS and ListenAndServeTLS, so it's not
* possible to modify the configuration with methods like
* tls.Config.SetSessionTicketKeys. To use
* SetSessionTicketKeys, use Server.Serve with a TLS Listener
* instead.
*/
TLSConfig?: any /* tls.Config */;
/**
* ReadTimeout is the maximum duration for reading the entire
* request, including the body. A zero or negative value means
* there will be no timeout.
* Because ReadTimeout does not let Handlers make per-request
* decisions on each request body's acceptable deadline or
* upload rate, most users will prefer to use
* ReadHeaderTimeout. It is valid to use them both.
*/
ReadTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* ReadHeaderTimeout is the amount of time allowed to read
* request headers. The connection's read deadline is reset
* after reading the headers and the Handler can decide what
* is considered too slow for the body. If ReadHeaderTimeout
* is zero, the value of ReadTimeout is used. If both are
* zero, there is no timeout.
*/
ReadHeaderTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* WriteTimeout is the maximum duration before timing out
* writes of the response. It is reset whenever a new
* request's header is read. Like ReadTimeout, it does not
* let Handlers make decisions on a per-request basis.
* A zero or negative value means there will be no timeout.
*/
WriteTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* IdleTimeout is the maximum amount of time to wait for the
* next request when keep-alives are enabled. If IdleTimeout
* is zero, the value of ReadTimeout is used. If both are
* zero, there is no timeout.
*/
IdleTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* MaxHeaderBytes controls the maximum number of bytes the
* server will read parsing the request header's keys and
* values, including the request line. It does not limit the
* size of the request body.
* If zero, DefaultMaxHeaderBytes is used.
*/
MaxHeaderBytes: number /* int */;
/**
* TLSNextProto optionally specifies a function to take over
* ownership of the provided TLS connection when an ALPN
* protocol upgrade has occurred. The map key is the protocol
* name negotiated. The Handler argument should be used to
* handle HTTP requests and will initialize the Request's TLS
* and RemoteAddr if not already set. The connection is
* automatically closed when the function returns.
* If TLSNextProto is not nil, HTTP/2 support is not enabled
* automatically.
*/
TLSNextProto: { [key: string]: any};
/**
* ConnState specifies an optional callback function that is
* called when a client connection changes state. See the
* ConnState type and associated constants for details.
*/
ConnState: any;
/**
* ErrorLog specifies an optional logger for errors accepting
* connections, unexpected behavior from handlers, and
* underlying FileSystem errors.
* If nil, logging is done via the log package's standard logger.
*/
ErrorLog?: any /* log.Logger */;
/**
* BaseContext optionally specifies a function that returns
* the base context for incoming requests on this server.
* The provided Listener is the specific Listener that's
* about to start accepting requests.
* If BaseContext is nil, the default is context.Background().
* If non-nil, it must return a non-nil context.
*/
BaseContext: any;
/**
* ConnContext optionally specifies a function that modifies
* the context used for a new connection c. The provided ctx
* is derived from the base context and has a ServerContextKey
* value.
*/
ConnContext: any;
}
/**
* shutdownPollIntervalMax is the max polling interval when checking
* quiescence during Server.Shutdown. Polling starts with a small
* interval and backs off to the max.
* Ideally we could find a solution that doesn't involve polling,
* but which also doesn't have a high runtime cost (and doesn't
* involve any contentious mutexes), but that is left as an
* exercise for the reader.
*/
/**
* A ConnState represents the state of a client connection to a server.
* It's used by the optional Server.ConnState hook.
*/
export type ConnState = number /* int */;
/**
* StateNew represents a new connection that is expected to
* send a request immediately. Connections begin at this
* state and then transition to either StateActive or
* StateClosed.
*/
export const StateNew: ConnState = 0;
/**
* StateActive represents a connection that has read 1 or more
* bytes of a request. The Server.ConnState hook for
* StateActive fires before the request has entered a handler
* and doesn't fire again until the request has been
* handled. After the request is handled, the state
* transitions to StateClosed, StateHijacked, or StateIdle.
* For HTTP/2, StateActive fires on the transition from zero
* to one active request, and only transitions away once all
* active requests are complete. That means that ConnState
* cannot be used to do per-request work; ConnState only notes
* the overall state of the connection.
*/
export const StateActive: ConnState = 1;
/**
* StateIdle represents a connection that has finished
* handling a request and is in the keep-alive state, waiting
* for a new request. Connections transition from StateIdle
* to either StateActive or StateClosed.
*/
export const StateIdle: ConnState = 2;
/**
* StateHijacked represents a hijacked connection.
* This is a terminal state. It does not transition to StateClosed.
*/
export const StateHijacked: ConnState = 3;
/**
* StateClosed represents a closed connection.
* This is a terminal state. Hijacked connections do not
* transition to StateClosed.
*/
export const StateClosed: ConnState = 4;
/**
* serverHandler delegates to either the server's Handler or
* DefaultServeMux and also handles "OPTIONS *" requests.
*/
/**
* onceCloseListener wraps a net.Listener, protecting it from
* multiple Close calls.
*/
/**
* globalOptionsHandler responds to "OPTIONS *" requests.
*/
/**
* initALPNRequest is an HTTP handler that initializes certain
* uninitialized fields in its *Request. Such partially-initialized
* Requests come from ALPN protocol handlers.
*/
/**
* loggingConn is used for debugging.
*/
/**
* checkConnErrorWriter writes to c.rwc and records any write errors to c.werr.
* It only contains one field (and a pointer field at that), so it
* fits in an interface value without an extra allocation.
*/
//////////
// source: sniff.go
/**
* The algorithm uses at most sniffLen bytes to make its decision.
*/
//////////
// source: socks_bundle.go
/**
* A Command represents a SOCKS command.
*/
/**
* An AuthMethod represents a SOCKS authentication method.
*/
/**
* A Reply represents a SOCKS command reply code.
*/
/**
* An Addr represents a SOCKS-specific address.
* Either Name or IP is used exclusively.
*/
/**
* A Conn represents a forward proxy connection.
*/
/**
* A Dialer holds SOCKS-specific options.
*/
/**
* UsernamePassword are the credentials for the username/password
* authentication method.
*/
//////////
// source: status.go
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusContinue = 100; // RFC 7231, 6.2.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusSwitchingProtocols = 101; // RFC 7231, 6.2.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusProcessing = 102; // RFC 2518, 10.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusEarlyHints = 103; // RFC 8297
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusOK = 200; // RFC 7231, 6.3.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusCreated = 201; // RFC 7231, 6.3.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusAccepted = 202; // RFC 7231, 6.3.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNonAuthoritativeInfo = 203; // RFC 7231, 6.3.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNoContent = 204; // RFC 7231, 6.3.5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusResetContent = 205; // RFC 7231, 6.3.6
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusPartialContent = 206; // RFC 7233, 4.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusMultiStatus = 207; // RFC 4918, 11.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusAlreadyReported = 208; // RFC 5842, 7.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusIMUsed = 226; // RFC 3229, 10.4.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusMultipleChoices = 300; // RFC 7231, 6.4.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusMovedPermanently = 301; // RFC 7231, 6.4.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusFound = 302; // RFC 7231, 6.4.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusSeeOther = 303; // RFC 7231, 6.4.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNotModified = 304; // RFC 7232, 4.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUseProxy = 305; // RFC 7231, 6.4.5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusTemporaryRedirect = 307; // RFC 7231, 6.4.7
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusPermanentRedirect = 308; // RFC 7538, 3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusBadRequest = 400; // RFC 7231, 6.5.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUnauthorized = 401; // RFC 7235, 3.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusPaymentRequired = 402; // RFC 7231, 6.5.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusForbidden = 403; // RFC 7231, 6.5.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNotFound = 404; // RFC 7231, 6.5.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusMethodNotAllowed = 405; // RFC 7231, 6.5.5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNotAcceptable = 406; // RFC 7231, 6.5.6
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusProxyAuthRequired = 407; // RFC 7235, 3.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusRequestTimeout = 408; // RFC 7231, 6.5.7
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusConflict = 409; // RFC 7231, 6.5.8
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusGone = 410; // RFC 7231, 6.5.9
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusLengthRequired = 411; // RFC 7231, 6.5.10
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusPreconditionFailed = 412; // RFC 7232, 4.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusRequestEntityTooLarge = 413; // RFC 7231, 6.5.11
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusRequestURITooLong = 414; // RFC 7231, 6.5.12
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUnsupportedMediaType = 415; // RFC 7231, 6.5.13
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusRequestedRangeNotSatisfiable = 416; // RFC 7233, 4.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusExpectationFailed = 417; // RFC 7231, 6.5.14
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusTeapot = 418; // RFC 7168, 2.3.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusMisdirectedRequest = 421; // RFC 7540, 9.1.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUnprocessableEntity = 422; // RFC 4918, 11.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusLocked = 423; // RFC 4918, 11.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusFailedDependency = 424; // RFC 4918, 11.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusTooEarly = 425; // RFC 8470, 5.2.
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUpgradeRequired = 426; // RFC 7231, 6.5.15
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusPreconditionRequired = 428; // RFC 6585, 3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusTooManyRequests = 429; // RFC 6585, 4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusRequestHeaderFieldsTooLarge = 431; // RFC 6585, 5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusUnavailableForLegalReasons = 451; // RFC 7725, 3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusInternalServerError = 500; // RFC 7231, 6.6.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNotImplemented = 501; // RFC 7231, 6.6.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusBadGateway = 502; // RFC 7231, 6.6.3
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusServiceUnavailable = 503; // RFC 7231, 6.6.4
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusGatewayTimeout = 504; // RFC 7231, 6.6.5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusHTTPVersionNotSupported = 505; // RFC 7231, 6.6.6
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusVariantAlsoNegotiates = 506; // RFC 2295, 8.1
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusInsufficientStorage = 507; // RFC 4918, 11.5
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusLoopDetected = 508; // RFC 5842, 7.2
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNotExtended = 510; // RFC 2774, 7
/**
* HTTP status codes as registered with IANA.
* See: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
*/
export const StatusNetworkAuthenticationRequired = 511; // RFC 6585, 6
//////////
// source: transfer.go
/**
* transferWriter inspects the fields of a user-supplied Request or Response,
* sanitizes them without changing the user object and provides methods for
* writing the respective header, body and trailer in wire format.
*/
/**
* unsupportedTEError reports unsupported transfer-encodings.
*/
/**
* body turns a Reader into a ReadCloser.
* Close ensures that the body has been fully read
* and then reads the trailer if necessary.
*/
/**
* bodyLocked is a io.Reader reading from a *body when its mutex is
* already held.
*/
/**
* finishAsyncByteRead finishes reading the 1-byte sniff
* from the ContentLength==0, Body!=nil case.
*/
/**
* bufioFlushWriter is an io.Writer wrapper that flushes all writes
* on its wrapped writer if it's a *bufio.Writer.
*/
//////////
// source: transport.go
/**
* DefaultMaxIdleConnsPerHost is the default value of Transport's
* MaxIdleConnsPerHost.
*/
export const DefaultMaxIdleConnsPerHost = 2;
/**
* Transport is an implementation of RoundTripper that supports HTTP,
* HTTPS, and HTTP proxies (for either HTTP or HTTPS with CONNECT).
* By default, Transport caches connections for future re-use.
* This may leave many open connections when accessing many hosts.
* This behavior can be managed using Transport's CloseIdleConnections method
* and the MaxIdleConnsPerHost and DisableKeepAlives fields.
* Transports should be reused instead of created as needed.
* Transports are safe for concurrent use by multiple goroutines.
* A Transport is a low-level primitive for making HTTP and HTTPS requests.
* For high-level functionality, such as cookies and redirects, see Client.
* Transport uses HTTP/1.1 for HTTP URLs and either HTTP/1.1 or HTTP/2
* for HTTPS URLs, depending on whether the server supports HTTP/2,
* and how the Transport is configured. The DefaultTransport supports HTTP/2.
* To explicitly enable HTTP/2 on a transport, use golang.org/x/net/http2
* and call ConfigureTransport. See the package docs for more about HTTP/2.
* Responses with status codes in the 1xx range are either handled
* automatically (100 expect-continue) or ignored. The one
* exception is HTTP status code 101 (Switching Protocols), which is
* considered a terminal status and returned by RoundTrip. To see the
* ignored 1xx responses, use the httptrace trace package's
* ClientTrace.Got1xxResponse.
* Transport only retries a request upon encountering a network error
* if the request is idempotent and either has no body or has its
* Request.GetBody defined. HTTP requests are considered idempotent if
* they have HTTP methods GET, HEAD, OPTIONS, or TRACE; or if their
* Header map contains an "Idempotency-Key" or "X-Idempotency-Key"
* entry. If the idempotency key value is a zero-length slice, the
* request is treated as idempotent but the header is not sent on the
* wire.
*/
export interface Transport {
/**
* Proxy specifies a function to return a proxy for a given
* Request. If the function returns a non-nil error, the
* request is aborted with the provided error.
* The proxy type is determined by the URL scheme. "http",
* "https", and "socks5" are supported. If the scheme is empty,
* "http" is assumed.
* If Proxy is nil or returns a nil *URL, no proxy is used.
*/
Proxy: any;
/**
* DialContext specifies the dial function for creating unencrypted TCP connections.
* If DialContext is nil (and the deprecated Dial below is also nil),
* then the transport dials using package net.
* DialContext runs concurrently with calls to RoundTrip.
* A RoundTrip call that initiates a dial may end up using
* a connection dialed previously when the earlier connection
* becomes idle before the later DialContext completes.
*/
DialContext: any;
/**
* Dial specifies the dial function for creating unencrypted TCP connections.
* Dial runs concurrently with calls to RoundTrip.
* A RoundTrip call that initiates a dial may end up using
* a connection dialed previously when the earlier connection
* becomes idle before the later Dial completes.
* Deprecated: Use DialContext instead, which allows the transport
* to cancel dials as soon as they are no longer needed.
* If both are set, DialContext takes priority.
*/
Dial: any;
/**
* DialTLSContext specifies an optional dial function for creating
* TLS connections for non-proxied HTTPS requests.
* If DialTLSContext is nil (and the deprecated DialTLS below is also nil),
* DialContext and TLSClientConfig are used.
* If DialTLSContext is set, the Dial and DialContext hooks are not used for HTTPS
* requests and the TLSClientConfig and TLSHandshakeTimeout
* are ignored. The returned net.Conn is assumed to already be
* past the TLS handshake.
*/
DialTLSContext: any;
/**
* DialTLS specifies an optional dial function for creating
* TLS connections for non-proxied HTTPS requests.
* Deprecated: Use DialTLSContext instead, which allows the transport
* to cancel dials as soon as they are no longer needed.
* If both are set, DialTLSContext takes priority.
*/
DialTLS: any;
/**
* TLSClientConfig specifies the TLS configuration to use with
* tls.Client.
* If nil, the default configuration is used.
* If non-nil, HTTP/2 support may not be enabled by default.
*/
TLSClientConfig?: any /* tls.Config */;
/**
* TLSHandshakeTimeout specifies the maximum amount of time waiting to
* wait for a TLS handshake. Zero means no timeout.
*/
TLSHandshakeTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* DisableKeepAlives, if true, disables HTTP keep-alives and
* will only use the connection to the server for a single
* HTTP request.
* This is unrelated to the similarly named TCP keep-alives.
*/
DisableKeepAlives: boolean;
/**
* DisableCompression, if true, prevents the Transport from
* requesting compression with an "Accept-Encoding: gzip"
* request header when the Request contains no existing
* Accept-Encoding value. If the Transport requests gzip on
* its own and gets a gzipped response, it's transparently
* decoded in the Response.Body. However, if the user
* explicitly requested gzip it is not automatically
* uncompressed.
*/
DisableCompression: boolean;
/**
* MaxIdleConns controls the maximum number of idle (keep-alive)
* connections across all hosts. Zero means no limit.
*/
MaxIdleConns: number /* int */;
/**
* MaxIdleConnsPerHost, if non-zero, controls the maximum idle
* (keep-alive) connections to keep per-host. If zero,
* DefaultMaxIdleConnsPerHost is used.
*/
MaxIdleConnsPerHost: number /* int */;
/**
* MaxConnsPerHost optionally limits the total number of
* connections per host, including connections in the dialing,
* active, and idle states. On limit violation, dials will block.
* Zero means no limit.
*/
MaxConnsPerHost: number /* int */;
/**
* IdleConnTimeout is the maximum amount of time an idle
* (keep-alive) connection will remain idle before closing
* itself.
* Zero means no limit.
*/
IdleConnTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* ResponseHeaderTimeout, if non-zero, specifies the amount of
* time to wait for a server's response headers after fully
* writing the request (including its body, if any). This
* time does not include the time to read the response body.
*/
ResponseHeaderTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* ExpectContinueTimeout, if non-zero, specifies the amount of
* time to wait for a server's first response headers after fully
* writing the request headers if the request has an
* "Expect: 100-continue" header. Zero means no timeout and
* causes the body to be sent immediately, without
* waiting for the server to approve.
* This time does not include the time to send the request header.
*/
ExpectContinueTimeout: number /* time in nanoseconds (time.Duration) */;
/**
* TLSNextProto specifies how the Transport switches to an
* alternate protocol (such as HTTP/2) after a TLS ALPN
* protocol negotiation. If Transport dials an TLS connection
* with a non-empty protocol name and TLSNextProto contains a
* map entry for that key (such as "h2"), then the func is
* called with the request's authority (such as "example.com"
* or "example.com:1234") and the TLS connection. The function
* must return a RoundTripper that then handles the request.
* If TLSNextProto is not nil, HTTP/2 support is not enabled
* automatically.
*/
TLSNextProto: { [key: string]: any};
/**
* ProxyConnectHeader optionally specifies headers to send to
* proxies during CONNECT requests.
* To set the header dynamically, see GetProxyConnectHeader.
*/
ProxyConnectHeader: Header;
/**
* GetProxyConnectHeader optionally specifies a func to return
* headers to send to proxyURL during a CONNECT request to the
* ip:port target.
* If it returns an error, the Transport's RoundTrip fails with
* that error. It can return (nil, nil) to not add headers.
* If GetProxyConnectHeader is non-nil, ProxyConnectHeader is
* ignored.
*/
GetProxyConnectHeader: any;
/**
* MaxResponseHeaderBytes specifies a limit on how many
* response bytes are allowed in the server's response
* header.
* Zero means to use a default limit.
*/
MaxResponseHeaderBytes: number /* int64 */;
/**
* WriteBufferSize specifies the size of the write buffer used
* when writing to the transport.
* If zero, a default (currently 4KB) is used.
*/
WriteBufferSize: number /* int */;
/**
* ReadBufferSize specifies the size of the read buffer used
* when reading from the transport.
* If zero, a default (currently 4KB) is used.
*/
ReadBufferSize: number /* int */;
/**
* ForceAttemptHTTP2 controls whether HTTP/2 is enabled when a non-zero
* Dial, DialTLS, or DialContext func or TLSClientConfig is provided.
* By default, use of any those fields conservatively disables HTTP/2.
* To use a custom dialer or TLS config and still attempt HTTP/2
* upgrades, set this to true.
*/
ForceAttemptHTTP2: boolean;
}
/**
* A cancelKey is the key of the reqCanceler map.
* We wrap the *Request in this type since we want to use the original request,
* not any transient one created by roundTrip.
*/
/**
* h2Transport is the interface we expect to be able to call from
* net/http against an *http2.Transport that's either bundled into
* h2_bundle.go or supplied by the user via x/net/http2.
* We name it with the "h2" prefix to stay out of the "http2" prefix
* namespace used by x/tools/cmd/bundle for h2_bundle.go.
*/
/**
* transportRequest is a wrapper around a *Request that adds
* optional extra headers to write and stores any error to return
* from roundTrip.
*/
/**
* transportReadFromServerError is used by Transport.readLoop when the
* 1 byte peek read fails and we're actually anticipating a response.
* Usually this is just due to the inherent keep-alive shut down race,
* where the server closed the connection at the same time the client
* wrote. The underlying err field is usually io.EOF or some
* ECONNRESET sort of thing which varies by platform. But it might be
* the user's custom net.Conn.Read error too, so we carry it along for
* them to return from Transport.RoundTrip.
*/
/**
* A wantConn records state about a wanted connection
* (that is, an active call to getConn).
* The conn may be gotten by dialing or by finding an idle connection,
* or a cancellation may make the conn no longer wanted.
* These three options are racing against each other and use
* wantConn to coordinate and agree about the winning outcome.
*/
/**
* A wantConnQueue is a queue of wantConns.
*/
/**
* persistConnWriter is the io.Writer written to by pc.bw.
* It accumulates the number of bytes written to the underlying conn,
* so the retry logic can determine whether any bytes made it across
* the wire.
* This is exactly 1 pointer field wide so it can go into an interface
* without allocation.
*/
/**
* connectMethod is the map key (in its String form) for keeping persistent
* TCP connections alive for subsequent HTTP requests.
* A connect method may be of the following types:
* connectMethod.key().String() Description
* ------------------------------ -------------------------
* |http|foo.com http directly to server, no proxy
* |https|foo.com https directly to server, no proxy
* |https,h1|foo.com https directly to server w/o HTTP/2, no proxy
* http://proxy.com|https|foo.com http to proxy, then CONNECT to foo.com
* http://proxy.com|http http to proxy, http to anywhere after that
* socks5://proxy.com|http|foo.com socks5 to proxy, then http to foo.com
* socks5://proxy.com|https|foo.com socks5 to proxy, then https to foo.com
* https://proxy.com|https|foo.com https to proxy, then CONNECT to foo.com
* https://proxy.com|http https to proxy, http to anywhere after that
*/
/**
* connectMethodKey is the map key version of connectMethod, with a
* stringified proxy URL (or the empty string) instead of a pointer to
* a URL.
*/
/**
* persistConn wraps a connection, usually a persistent one
* (but may be used for non-keep-alive requests as well)
*/
/**
* readWriteCloserBody is the Response.Body type used when we want to
* give users write access to the Body through the underlying
* connection (TCP, unless using custom dialers). This is then
* the concrete type for a Response.Body on the 101 Switching
* Protocols response, as used by WebSockets, h2c, etc.
*/
/**
* nothingWrittenError wraps a write errors which ended up writing zero bytes.
*/
/**
* maxWriteWaitBeforeConnReuse is how long the a Transport RoundTrip
* will wait to see the Request's Body.Write result after getting a
* response from the server. See comments in (*persistConn).wroteRequest.
*/
/**
* responseAndError is how the goroutine reading from an HTTP/1 server
* communicates with the goroutine doing the RoundTrip.
*/
/**
* A writeRequest is sent by the readLoop's goroutine to the
* writeLoop's goroutine to write a request while the read loop
* concurrently waits on both the write response and the server's
* reply.
*/
/**
* tLogKey is a context WithValue key for test debugging contexts containing
* a t.Logf func. See export_test.go's Request.WithT method.
*/
/**
* bodyEOFSignal is used by the HTTP/1 transport when reading response
* bodies to make sure we see the end of a response body before
* proceeding and reading on the connection again.
* It wraps a ReadCloser but runs fn (if non-nil) at most
* once, right before its final (error-producing) Read or Close call
* returns. fn should return the new error to return from Read or Close.
* If earlyCloseFn is non-nil and Close is called before io.EOF is
* seen, earlyCloseFn is called instead of fn, and its return value is
* the return value from Close.
*/
/**
* gzipReader wraps a response body so it can lazily
* call gzip.NewReader on the first call to Read
*/
/**
* fakeLocker is a sync.Locker which does nothing. It's used to guard
* test-only fields when not under test, to avoid runtime atomic
* overhead.
*/
Raw
time.ts
// "time" package tygo output
// Code generated by tygo. DO NOT EDIT.
//////////
// source: format.go
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const Layout = "01/02 03:04:05PM '06 -0700"; // The reference time, in numerical order.
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const ANSIC = "Mon Jan _2 15:04:05 2006";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const UnixDate = "Mon Jan _2 15:04:05 MST 2006";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RubyDate = "Mon Jan 02 15:04:05 -0700 2006";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC822 = "02 Jan 06 15:04 MST";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC822Z = "02 Jan 06 15:04 -0700"; // RFC822 with numeric zone
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC850 = "Monday, 02-Jan-06 15:04:05 MST";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700"; // RFC1123 with numeric zone
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC3339 = "2006-01-02T15:04:05Z07:00";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const Kitchen = "3:04PM";
/**
* Handy time stamps.
*/
export const Stamp = "Jan _2 15:04:05";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const StampMilli = "Jan _2 15:04:05.000";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const StampMicro = "Jan _2 15:04:05.000000";
/**
* These are predefined layouts for use in Time.Format and time.Parse.
* The reference time used in these layouts is the specific time stamp:
* 01/02 03:04:05PM '06 -0700
* (January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
* That value is recorded as the constant named Layout, listed below. As a Unix
* time, this is 1136239445. Since MST is GMT-0700, the reference would be
* printed by the Unix date command as:
* Mon Jan 2 15:04:05 MST 2006
* It is a regrettable historic error that the date uses the American convention
* of putting the numerical month before the day.
* The example for Time.Format demonstrates the working of the layout string
* in detail and is a good reference.
* Note that the RFC822, RFC850, and RFC1123 formats should be applied
* only to local times. Applying them to UTC times will use "UTC" as the
* time zone abbreviation, while strictly speaking those RFCs require the
* use of "GMT" in that case.
* In general RFC1123Z should be used instead of RFC1123 for servers
* that insist on that format, and RFC3339 should be preferred for new protocols.
* RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
* when used with time.Parse they do not accept all the time formats
* permitted by the RFCs and they do accept time formats not formally defined.
* The RFC3339Nano format removes trailing zeros from the seconds field
* and thus may not sort correctly once formatted.
* Most programs can use one of the defined constants as the layout passed to
* Format or Parse. The rest of this comment can be ignored unless you are
* creating a custom layout string.
* To define your own format, write down what the reference time would look like
* formatted your way; see the values of constants like ANSIC, StampMicro or
* Kitchen for examples. The model is to demonstrate what the reference time
* looks like so that the Format and Parse methods can apply the same
* transformation to a general time value.
* Here is a summary of the components of a layout string. Each element shows by
* example the formatting of an element of the reference time. Only these values
* are recognized. Text in the layout string that is not recognized as part of
* the reference time is echoed verbatim during Format and expected to appear
* verbatim in the input to Parse.
* Year: "2006" "06"
* Month: "Jan" "January"
* Textual day of the week: "Mon" "Monday"
* Numeric day of the month: "2" "_2" "02"
* Numeric day of the year: "__2" "002"
* Hour: "15" "3" "03" (PM or AM)
* Minute: "4" "04"
* Second: "5" "05"
* AM/PM mark: "PM"
* Numeric time zone offsets format as follows:
* "-0700" ±hhmm
* "-07:00" ±hh:mm
* "-07" ±hh
* Replacing the sign in the format with a Z triggers
* the ISO 8601 behavior of printing Z instead of an
* offset for the UTC zone. Thus:
* "Z0700" Z or ±hhmm
* "Z07:00" Z or ±hh:mm
* "Z07" Z or ±hh
* Within the format string, the underscores in "_2" and "__2" represent spaces
* that may be replaced by digits if the following number has multiple digits,
* for compatibility with fixed-width Unix time formats. A leading zero represents
* a zero-padded value.
* The formats and 002 are space-padded and zero-padded
* three-character day of year; there is no unpadded day of year format.
* A comma or decimal point followed by one or more zeros represents
* a fractional second, printed to the given number of decimal places.
* A comma or decimal point followed by one or more nines represents
* a fractional second, printed to the given number of decimal places, with
* trailing zeros removed.
* For example "15:04:05,000" or "15:04:05.000" formats or parses with
* millisecond precision.
* Some valid layouts are invalid time values for time.Parse, due to formats
* such as _ for space padding and Z for zone information.
*/
export const StampNano = "Jan _2 15:04:05.000000000";
/**
* ParseError describes a problem parsing a time string.
*/
export interface ParseError {
Layout: string;
Value: string;
LayoutElem: string;
ValueElem: string;
Message: string;
}
//////////
// source: sleep.go
/**
* Interface to timers implemented in package runtime.
* Must be in sync with ../runtime/time.go:/^type timer
*/
/**
* The Timer type represents a single event.
* When the Timer expires, the current time will be sent on C,
* unless the Timer was created by AfterFunc.
* A Timer must be created with NewTimer or AfterFunc.
*/
export interface Timer {
C: any;
}
//////////
// source: tick.go
/**
* A Ticker holds a channel that delivers ``ticks'' of a clock
* at intervals.
*/
export interface Ticker {
C: any; // The channel on which the ticks are delivered.
}
//////////
// source: time.go
/*
Package time provides functionality for measuring and displaying time.
The calendrical calculations always assume a Gregorian calendar, with
no leap seconds.
Monotonic Clocks
Operating systems provide both a “wall clock,” which is subject to
changes for clock synchronization, and a “monotonic clock,” which is
not. The general rule is that the wall clock is for telling time and
the monotonic clock is for measuring time. Rather than split the API,
in this package the Time returned by time.Now contains both a wall
clock reading and a monotonic clock reading; later time-telling
operations use the wall clock reading, but later time-measuring
operations, specifically comparisons and subtractions, use the
monotonic clock reading.
For example, this code always computes a positive elapsed time of
approximately 20 milliseconds, even if the wall clock is changed during
the operation being timed:
start := time.Now()
... operation that takes 20 milliseconds ...
t := time.Now()
elapsed := t.Sub(start)
Other idioms, such as time.Since(start), time.Until(deadline), and
time.Now().Before(deadline), are similarly robust against wall clock
resets.
The rest of this section gives the precise details of how operations
use monotonic clocks, but understanding those details is not required
to use this package.
The Time returned by time.Now contains a monotonic clock reading.
If Time t has a monotonic clock reading, t.Add adds the same duration to
both the wall clock and monotonic clock readings to compute the result.
Because t.AddDate(y, m, d), t.Round(d), and t.Truncate(d) are wall time
computations, they always strip any monotonic clock reading from their results.
Because t.In, t.Local, and t.UTC are used for their effect on the interpretation
of the wall time, they also strip any monotonic clock reading from their results.
The canonical way to strip a monotonic clock reading is to use t = t.Round(0).
If Times t and u both contain monotonic clock readings, the operations
t.After(u), t.Before(u), t.Equal(u), and t.Sub(u) are carried out
using the monotonic clock readings alone, ignoring the wall clock
readings. If either t or u contains no monotonic clock reading, these
operations fall back to using the wall clock readings.
On some systems the monotonic clock will stop if the computer goes to sleep.
On such a system, t.Sub(u) may not accurately reflect the actual
time that passed between t and u.
Because the monotonic clock reading has no meaning outside
the current process, the serialized forms generated by t.GobEncode,
t.MarshalBinary, t.MarshalJSON, and t.MarshalText omit the monotonic
clock reading, and t.Format provides no format for it. Similarly, the
constructors time.Date, time.Parse, time.ParseInLocation, and time.Unix,
as well as the unmarshalers t.GobDecode, t.UnmarshalBinary.
t.UnmarshalJSON, and t.UnmarshalText always create times with
no monotonic clock reading.
Note that the Go == operator compares not just the time instant but
also the Location and the monotonic clock reading. See the
documentation for the Time type for a discussion of equality
testing for Time values.
For debugging, the result of t.String does include the monotonic
clock reading if present. If t != u because of different monotonic clock readings,
that difference will be visible when printing t.String() and u.String().
*/
/**
* A Time represents an instant in time with nanosecond precision.
* Programs using times should typically store and pass them as values,
* not pointers. That is, time variables and struct fields should be of
* type time.Time, not *time.Time.
* A Time value can be used by multiple goroutines simultaneously except
* that the methods GobDecode, UnmarshalBinary, UnmarshalJSON and
* UnmarshalText are not concurrency-safe.
* Time instants can be compared using the Before, After, and Equal methods.
* The Sub method subtracts two instants, producing a Duration.
* The Add method adds a Time and a Duration, producing a Time.
* The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC.
* As this time is unlikely to come up in practice, the IsZero method gives
* a simple way of detecting a time that has not been initialized explicitly.
* Each Time has associated with it a Location, consulted when computing the
* presentation form of the time, such as in the Format, Hour, and Year methods.
* The methods Local, UTC, and In return a Time with a specific location.
* Changing the location in this way changes only the presentation; it does not
* change the instant in time being denoted and therefore does not affect the
* computations described in earlier paragraphs.
* Representations of a Time value saved by the GobEncode, MarshalBinary,
* MarshalJSON, and MarshalText methods store the Time.Location's offset, but not
* the location name. They therefore lose information about Daylight Saving Time.
* In addition to the required “wall clock” reading, a Time may contain an optional
* reading of the current process's monotonic clock, to provide additional precision
* for comparison or subtraction.
* See the “Monotonic Clocks” section in the package documentation for details.
* Note that the Go == operator compares not just the time instant but also the
* Location and the monotonic clock reading. Therefore, Time values should not
* be used as map or database keys without first guaranteeing that the
* identical Location has been set for all values, which can be achieved
* through use of the UTC or Local method, and that the monotonic clock reading
* has been stripped by setting t = t.Round(0). In general, prefer t.Equal(u)
* to t == u, since t.Equal uses the most accurate comparison available and
* correctly handles the case when only one of its arguments has a monotonic
* clock reading.
*/
export interface Time {
}
/**
* A Month specifies a month of the year (January = 1, ...).
*/
export type Month = number /* int */;
export const January: Month = 1;
export const February: Month = 2;
export const March: Month = 3;
export const April: Month = 4;
export const May: Month = 5;
export const June: Month = 6;
export const July: Month = 7;
export const August: Month = 8;
export const September: Month = 9;
export const October: Month = 10;
export const November: Month = 11;
export const December: Month = 12;
/**
* A Weekday specifies a day of the week (Sunday = 0, ...).
*/
export type Weekday = number /* int */;
export const Sunday: Weekday = 0;
export const Monday: Weekday = 1;
export const Tuesday: Weekday = 2;
export const Wednesday: Weekday = 3;
export const Thursday: Weekday = 4;
export const Friday: Weekday = 5;
export const Saturday: Weekday = 6;
/**
* A Duration represents the elapsed time between two instants
* as an int64 nanosecond count. The representation limits the
* largest representable duration to approximately 290 years.
*/
export type Duration = number /* int64 */;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Nanosecond: Duration = 1;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Microsecond = 1000 * Nanosecond;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Millisecond = 1000 * Microsecond;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Second = 1000 * Millisecond;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Minute = 60 * Second;
/**
* Common durations. There is no definition for units of Day or larger
* to avoid confusion across daylight savings time zone transitions.
* To count the number of units in a Duration, divide:
* second := time.Second
* fmt.Print(int64(second/time.Millisecond)) // prints 1000
* To convert an integer number of units to a Duration, multiply:
* seconds := 10
* fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
*/
export const Hour = 60 * Minute;
//////////
// source: zoneinfo.go
/**
* A Location maps time instants to the zone in use at that time.
* Typically, the Location represents the collection of time offsets
* in use in a geographical area. For many Locations the time offset varies
* depending on whether daylight savings time is in use at the time instant.
*/
export interface Location {
}
/**
* A zone represents a single time zone such as CET.
*/
/**
* A zoneTrans represents a single time zone transition.
*/
/**
* ruleKind is the kinds of rules that can be seen in a tzset string.
*/
/**
* rule is a rule read from a tzset string.
*/
//////////
// source: zoneinfo_read.go
/**
* maxFileSize is the max permitted size of files read by readFile.
* As reference, the zoneinfo.zip distributed by Go is ~350 KB,
* so 10MB is overkill.
*/
/**
* Simple I/O interface to binary blob of data.
*/
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NUTCLocal = 0;
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NStdWall = 1;
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NLeap = 2;
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NTime = 3;
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NZone = 4;
/**
* six big-endian 32-bit integers:
* number of UTC/local indicators
* number of standard/wall indicators
* number of leap seconds
* number of transition times
* number of local time zones
* number of characters of time zone abbrev strings
*/
export const NChar = 5;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment