forked from square/okhttp
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sync origin #12
Merged
Merged
sync origin #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GzipSource beginnings.
Should we later support random access for other primitives or random bulk access, I'd like the prefix to stay constant (getByte, getInt, getLong, getBytes) vs. the suffix (byteAt, intAt, longAt). Prefixing may work better for autocomplete in IDEs, particularly since we already use a prefix for our consuming reads (readByte, readInt, readLong).
GzipSource exceptions used six hex digits instead of 8 to print ints. readUtf8 always did an extra copy of the bytes being read. Moving bytes between buffers crashed when the destination was empty and the source was a prefix. InputStream reading returned values in -128..127 instead of in 0..255.
Rename byteAt to getByte.
Fix some OkBuffer bugs.
Initial implementation of an OkHttp-backed curl clone.
OkHttp no longer uses default ssl context.
Add -X to okcurl, permitting HEAD requests
This isn't quite as simple as I had hoped. We still lack something like DataInputStream/BufferedInputStream that combines a buffer with a Source. That means there's a bunch of methods that must manually refill the buffer before acting upon it. I'm going to continue to migrate code, and will follow up with changes to simplify this interaction.
…urce Use OkBuffer in spdy/3 source stream.
…urce Use OkBuffer in http/2 source stream
The Source API is nice for source implementors: no annoying skip method, no annoying available() method, just one API to supply bytes to the caller. But it isn't as nice of an API for source callers. It lacks convenient APIs! This bridges the gap. Calling code should use BufferedSource, and implementing code should implement Source.
BufferedSource.
Use OkBuffer in SpdyStream.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.