http-kit is a minimalist, event-driven, high-performance Clojure HTTP server/client library with WebSocket and asynchronous support

Related tags

HTTP Clients clojure async websockets http-client http-server
Overview

HTTP Kit

A simple, high-performance event-driven HTTP client+server for Clojure

CHANGELOG | API | current Break Version:

[http-kit "2.5.3"]  ; Published by contributors, see CHANGELOG for details
[http-kit "2.1.19"] ; Legacy, published by @shenfeng

Project status

http-kit's author (@shenfeng) unfortunately hasn't had much time to maintain http-kit recently. To help out I'll be doing basic issue triage, accepting minor/obvious PRs, etc.

A big thank you to the current contributors for keeping the project going! Additional contributors welcome: please ping me if you'd be interested in lending a hand.

See the (unmaintained, outdated) project website for original documentation, examples, benchmarks, etc.

- @ptaoussanis

Features

  • Ring compliant: HTTP Kit is an (almost) drop-in replacement for the standard Ring Jetty adapter. So you can use it with all your current libraries (e.g. Compojure) and middleware.

  • High performance: Using an event-driven architecture like Nginx, HTTP-kit is very, very fast. It comfortably handles tens of thousands of requests/sec on even midrange hardware. Here is another test about how it stacks up with others.

  • High concurrency: It's not only fast, but efficient! Each connection costs nothing but a few kB of memory. RAM usage grows O(n) with connections.

  • Clean, simple, small: Written from the ground-up to be lean, the entire client/server is available as a single ~90kB JAR with zero dependencies and ~3k lines of (mostly Java) code.

  • Sync or async: Synchronous is simple. Asynchronous is fast & flexible. With HTTP Kit you get the best of both with a simple API that lets you mix & match to best fit your use case.

  • WebSockets and Comet: With great out-the-box support for both WebSockets and efficient handling of long-held HTTP requests, realtime web applications are a breeze to write.

Enabling client SNI support (DISABLED BY DEFAULT)

To retain backwards-compatibility with JVMs < 8, http-kit client's SNI support is DISABLED by default.

Common cause of: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

This default may be changed in a future breaking release. In the meantime, manually enabling support is easy:

  (:require [org.httpkit.sni-client :as sni-client]) ; Needs Java >= 8, http-kit >= 2.4.0-alpha6

  ;; Change default client for your whole application:
  (alter-var-root #'org.httpkit.client/*default-client* (fn [_] sni-client/default-client))

  ;; or temporarily change default client for a particular thread context:
  (binding [org.httpkit.client/*default-client* sni-client/default-client]
    <...>)

See org.httpkit.client/*default-client* docstring for more details.

Hack locally

Hacker friendly: zero dependencies, written from the ground-up with only ~3.5k lines of code (including java), clean and tidy.

# Modify as you want, unit tests back you up:
lein test

# May be useful (more info), see `server_test.clj`:
./scripts/start_test_server

# Some numbers on how fast can http-kit's client can run:
lein test :benchmark

Contact & Contribution

Please use the GitHub issues page for feature suggestions, bug reports, or general discussions. Current contributors are listed here. The project website is also on GitHub.

Native Image

http-kit server and client are compatible with GraalVM's native-image compiler.

To ensure the image can build, provide the following options to the native-image compiler:

Reflection

In your reflection-config.json

{"name": "java.lang.reflect.AccessibleObject",
 "methods" : [{"name":"canAccess"}]}

Class initialization

As of version 2.5.2 add the following flags:

--initialize-at-run-time=org.httpkit.client.ClientSslEngineFactory\$SSLHolder

License

Copyright © 2012-2020 @shenfeng and contributors. Distributed under the Apache License Version 2.0.

Comments
  • HTTPS support?

    HTTPS support?

    It seems that http-kit client does not support HTTPS protocol.

    A lot of the sites now automatically redirect to a HTTPS address.

    Is support forthcoming, or else is there anything I can do to help?

    opened by laczoka 43
  • Normal HTTP requests and Websockets handling

    Normal HTTP requests and Websockets handling

    Hello,

    I am trying to figure out from the documentation if its possible with one server instance on a port to handle both normal http requests and websocket requests.

    Can you please point me out a sample (if any) , documentation or maybe a pseudocode on how to achieve this?

    Thank you for your time

    opened by alolis 20
  • BREAKING: HTTP client clean-up and API tweaks

    BREAKING: HTTP client clean-up and API tweaks

    I've made quite a few different breaking changes here. No need to merge any of this, again just looking to start a discussion and get your thoughts.

    Biggest changes and motivation:

    • Renamed the fns (now init-client, http-get, http-post) to avoid name clashes with clojure.core. This isn't necessary, but I think it is convenient to avoid a clash if possible.
    • http-get and http-post now take an explicit client argument instead of using an internal atom. This allows defining and using multiple clients with different configs.
    • Renamed some arguments for clarity: keyify? -> keywordize-headers?, binary? -> binary-resp?, cb -> callback, body -> data.
    • http-get and http-post now take destructured args, and a mandatory url for more convenient calling.
    opened by ptaoussanis 17
  • Consider

    Consider "easy" sync interface which does error handling for you, like clj-http?

    I'm considering to adopt http-kit client in babashka so it can be used for scripting.

    One thing that's different in http-kit vs clj-http is that when used synchronously, you have to check for :error and/or :status and then throw yourself (or do some other handling). But this requires writing a bunch of boilerplate. I reckon every httpkit user has their own boilerplate for this.

    That's why I'm also considering adding a synchronous interface over httpkit, in a namespace called babashka.http-client which does deref for you, if there's an :error, it will throw the error and it will also throw on a selection on status codes, like clj-http does, unless :throw is false. Is something like this maybe considered for httpkit proper?

    If babashka users want the async httpkit, they can just use the existing http-kit namespaces.

    I'm also considering to enable the SNI client by default, so that boilerplate isn't needed either.

    Please let me know if I'm overlooking something, I've only recently started looking at httpkit. I usually just want my script to exit with an error in case of a faulty request.

    See https://github.com/borkdude/babashka/issues/561

    enhancement pull-requests welcome client 
    opened by borkdude 16
  • initial websockets message comes before I get a chance to hook on-receive

    initial websockets message comes before I get a chance to hook on-receive

    I'm a happy user of http-kit. On server I have a http-kit-powered web-sockets server in Clojure and on browser side I have a web-sockets client in ClojureScript.

    The problem is that my implementation is flaky. My app suffers from occasional and very rare situations when initial :ready message sent from client to server gets lost. This usually happens in dev scenario where both client and server run on localhost and both processes are cold.

    I have a theory what is going wrong and I'm afraid it is a fundamental issue of http-kit API design.

    This is my server code:

    (defn on-new-client-connection [server request]
  (http/with-channel request channel
    (if-not (http/websocket? channel)
      {:status 200 :body "Please connect with a websocket client!"}
      (let [client (make-client channel)]
        (http/on-receive channel (partial add-job! client :receive server client))
        (http/on-close channel (partial add-job! client :close server client))
        (boot-client! server client)))))

    Imagine that client sends the initial :ready message ASAP after opening connection and this Clojure code is slow for some reason. There is a non-zero time window between with-channel and http/on-receive calls. If message is fast enough and comes before http/on-receive it gets silently lost.

    Unfortunately it is pretty hard to reproduce this issue in the above code. But obviously the problem can be amplified by putting something like (Thread/sleep 1000) before http/on-receive.

    After reading http-kit code, I believe there is no way how to hook http/on-receive to 100% prevent this scenario, because channel is given to the callback after connection has been initiated. And as far as I'm aware there is no "replay" mechanism, which would replay previously received messages after late http/on-receive call.

    Ideas?

    For reference full implementation is here: https://github.com/binaryage/dirac/blob/master/src/lib/dirac/lib/ws_client.cljs https://github.com/binaryage/dirac/blob/master/src/lib/dirac/lib/ws_server.clj

    pull-requests welcome ideas welcome server needs investigation bug? 
    opened by darwin 16
  • SSL error on `doRead`

    SSL error on `doRead`

    I'm getting javax.crypto.BadPaddingException exception which may be caused by synchronization. I'm not sure if this bug can be fixed on httpkit or just by updating java version :thinking:

    I'm using

    • http-kit 2.5.3
    • java openjdk version "11.0.11" 2021-04-20
    Exception stack 
    javax.crypto.BadPaddingException: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than or equal to IV size (8) + tag size (16)
  ?, in sun.security.ssl/decrypt
  ?, in sun.security.ssl/decodeInputRecord
  ?, in sun.security.ssl/decode
  ?, in sun.security.ssl/decode
  ?, in sun.security.ssl/decode
  ?, in sun.security.ssl/decode
  ?, in sun.security.ssl/readRecord
  ?, in sun.security.ssl/unwrap
  ?, in sun.security.ssl/unwrap
  ?, in javax.net.ssl/unwrap
  File "HttpsRequest.java", line 35, in org.httpkit.client/unwrapRead
    while ((res = engine.unwrap(peerNetData, peerAppData)).getStatus() == Status.OK) {
  File "HttpClient.java", line 191, in org.httpkit.client/doRead
    read = httpsReq.unwrapRead(buffer);
  File "HttpClient.java", line 494, in org.httpkit.client/run
    doRead(key, now);
  ?, in java.lang/run
    bug client 
    opened by daniel-quintoandar 15
  • WebSocket reserved bits error

    WebSocket reserved bits error

    Hi,

    I am using http-kit 2.1.13 for our app running on Heroku. We make use of websockets to deliver data from server to client, with Carmine.

    It works most of the time, but we occasionally get the following error about reserved bits:

    WebSocket connection to 'wss://staging.paddleguru.com/results/stream' failed: One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0

    Any ideas what could be causing this?

    server needs investigation 
    opened by dpetrovics 15

  • "http server loop error, should not happen" with "java.lang.NumberFormatException"

    Hi, first, thanks for http-kit. We love it - especially brilliant is how having so few dependencies helps avoid conflicts!

    I found the following exception in my logs today, and I've never seen anything like it.

    Tue Aug 06 17:31:03 UTC 2019 [server-loop] ERROR - http server loop error, should not happen
java.lang.NumberFormatException: For input string: "a9fe]"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.valueOf(Integer.java:766)
	at org.httpkit.server.HttpRequest.setHeaders(HttpRequest.java:79)
	at org.httpkit.server.HttpDecoder.readHeaders(HttpDecoder.java:269)
	at org.httpkit.server.HttpDecoder.decode(HttpDecoder.java:186)
	at org.httpkit.server.HttpServer.decodeHttp(HttpServer.java:154)
	at org.httpkit.server.HttpServer.doRead(HttpServer.java:233)
	at org.httpkit.server.HttpServer.run(HttpServer.java:349)
	at java.lang.Thread.run(Thread.java:748)

    Some system details, happy to provide any others that may be helpful:

    $ lein --version
Leiningen 2.9.1 on Java 1.8.0_222 OpenJDK

    http-kit version: 2.3.0

    Anyone encountered this before? Some googling revealed a similar looking one, but that came with some Key related exception instead of this number parsing one.

    Turning everything off and back on again has got me running again, but maybe this report will help uncover a bug.

    Thanks again.

    opened by harold 14
  • Minimal fix to add SNI support to client

    Minimal fix to add SNI support to client

    Here is an initial effort at resolving #187. I welcome any feedback, since I am not very familiar with the http-kit code or the async NIO library.

    This works for my particular situation, but there are a couple of caveats:

    1. This code is Java 8 only. If there is a need to support older versions of Java, this logic will need to be wrapped.
    2. It’s possible that a bad hostname could result in an IllegalArgumentException. Is it better for that to be allowed to bubble up or should it be swallowed and the SNI support disabled.

    Lastly, is this the righ insertion point for adding the SNI support? I do not know if there could be any race conditions or shared state that could result from this.

    enhancement pull-requests welcome ideas welcome client 
    opened by sattvik 14
  • Timeouts under high load with 2.1.17 and 2.1.18

    Timeouts under high load with 2.1.17 and 2.1.18

    http-kit versions 2.1.17 and 2.1.18 have rare, random timeouts with high load. Version 2.1.16 and earlier work without timeouts.

    Tests are run against this code https://github.com/jsyrjala/http-kit-perf . Tested with ab

    Failing ab runs looks like this. Timeouts don't happen on every run, but run it a few times, and you should see this behavior.

    ab -n 10000 -c 100 http://localhost:9876/                      
This is ApacheBench, Version 2.3 <$Revision: 1554214 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
apr_pollset_poll: The timeout specified has expired (70007)
Total of 9994 requests completed
    bug server priority 
    opened by jsyrjala 14
  • AsyncChannel's remote socket can be null, still reports open

    AsyncChannel's remote socket can be null, still reports open

    I've found a case where a channel reports being open, but prints like this:

    #<AsyncChannel 0.0.0.0/0.0.0.0:8080<->null>

    Not sure how I managed to get it into that state. Calling "close" DOES work, but I don't have any way to query for this state in my clojure code (since the relevant state holding the socket is private).

    Here's the stacktrace when I try to send! into such a channel:

    Thu Nov 07 18:30:00 PST 2013 [clojure-agent-send-off-pool-7] ERROR - increase :queue-size if this happens often
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@791fe0f4 rejected from java.util.concurrent.ThreadPoolExecutor@58ff2578[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 287]
    at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
    at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
    at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
    at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:110)
    at org.httpkit.server.RingHandler.clientClose(RingHandler.java:214)
    at org.httpkit.server.HttpServer.closeKey(HttpServer.java:72)
    at org.httpkit.server.HttpServer.tryWrite(HttpServer.java:216)
    at org.httpkit.server.HttpServer.tryWrite(HttpServer.java:190)
    at org.httpkit.server.AsyncChannel.send(AsyncChannel.java:225)
    at org.httpkit.server$eval21583$fn__21588.invoke(server.clj:83)
    at org.httpkit.server$eval21497$fn__21533$G__21482__21546.invoke(server.clj:35)
    at paddleguru.websocket$broadcast_BANG_$fn__47109.invoke(websocket.clj:30)
    at paddleguru.websocket$broadcast_BANG_.invoke(websocket.clj:30)
    at paddleguru.websocket.PubSub$fn__30814.invoke(websocket.clj:37)
    at paddleguru.websocket.PubSub$fn__30805.invoke(websocket.clj:35)
    at paddleguru.websocket.PubSub$fn__30817$fn__30818.invoke(websocket.clj:35)
    at paddleguru.websocket.PubSub$fn__30817.invoke(websocket.clj:35)
    at clojure.lang.AFn.applyToHelper(AFn.java:159)
    at clojure.lang.AFn.applyTo(AFn.java:151)
    at clojure.core$apply.invoke(core.clj:617)
    at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1788)
    at clojure.lang.RestFn.invoke(RestFn.java:425)
    at clojure.lang.AFn.applyToHelper(AFn.java:163)
    at clojure.lang.RestFn.applyTo(RestFn.java:132)
    at clojure.core$apply.invoke(core.clj:621)
    at clojure.core$bound_fn_STAR_$fn__4102.doInvoke(core.clj:1810)
    at clojure.lang.RestFn.invoke(RestFn.java:397)
    at clojure.core$binding_conveyor_fn$fn__4107.invoke(core.clj:1836)
    at clojure.lang.AFn.call(AFn.java:18)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)
    opened by sritchie 14
  • HTTP Client suggestion for cookies and multiple headers

    HTTP Client suggestion for cookies and multiple headers

    Hi, I recently wanted to switch to http-kit over clj-http since it seems to have better performance, but I noticed handling cookies is tricky. The resulting :set-cookie header has all of the cookies concatenated with , but for example in a cookie's Expires field there can also be ,s so it makes it tricky to parse.

    My suggestion is to instead concatenate multiple headers with \n instead so then the end user can easily split on \n to get the multiple values.

    I was going to try to fork and make a PR but when I run lein test locally on the unchanged code I get 8 test fails. So I'm not sure about my setup.

    The change I'm suggesting is java/org/httpkit/HttpUtils.java in the splitAndAddHeader method, line 378 replace the "," for "\n"

    This then results in 3 new test failures that can be fixed by changing test/org/httpkit/client_test.clj tests: test-header-multiple-values and test-headers-stringified to use \n instead of , on lines 457, 458, and 465.

    enhancement pull-requests welcome 
    opened by g23 1
  • Websocket fix

    Websocket fix

    A fix to the Websocket terminating due to having Content-Length: 0 in the header, when the application is deployed to Azure App Service. Detailed description can be found at: https://github.com/http-kit/http-kit/issues/498

    According to RFC 7230:

       A server MUST NOT send a Content-Length header field in any response
   with a status code of 1xx (Informational) or 204 (No Content).  ...

    In this fix, we check status code passed to org.httpkit.HttpEncode and skips adding the content-length header if the status is either 1xx or 204.

    bug server 
    opened by davidhjp01 0
  • Content-Length header set on Websocket upgrade request

    Content-Length header set on Websocket upgrade request

    HTTP requests with empty body will have Content-Length 0 set by default by the HttpEncode class, whenever Transfer-Encoding is not present. See the following snippet from HttpUtils.java, line 454:

    if (!CHUNKED.equals(headers.get("Transfer-Encoding"))) {
   if (bodyBuffer != null) {
      // trust the computed length
      headers.putOrReplace(CONTENT_LENGTH, Integer.toString(bodyBuffer.remaining()));
   } else {
      headers.putOrReplace(CONTENT_LENGTH, "0");
   }
}

    This will include, among other things, the WebSocket upgrade response. Setting Content-Length on this was causing problems with the HTTP proxy on Azure App Service, which terminated the connection instead of relaying the response.

    While Microsoft might fix the above, we also noticed this from the standard: https://www.rfc-editor.org/rfc/rfc7230#section-3.3.2

    A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).

    https://www.rfc-editor.org/rfc/rfc7230#section-3.3.2

    1. Any response to a HEAD request and any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body.

    So at the very least Content-Length seems superfluous in these cases, even though the body size is 0 bytes, and it may cause issues with proxies as we have seen with Azure App Service.

    We also tested two other server implementations; spring websockets and jetty 10. Neither sets Content-Length on the upgrade request. So we suggest a change here that takes at least the Websocket upgrade request headers into account before setting Content-Length. We have a working prototype of this that we can submit as a PR.

    bug pull-requests welcome server 
    opened by restenb 2
  • Direct (non heap) memory leaks caused by serving bigger files (like videos)

    Direct (non heap) memory leaks caused by serving bigger files (like videos)

    When a file is bigger than the org.http-kit.memmap-file-threshold (20MB by default) then MappedByteBuffer is used, which is not so easy to GC and http-kit seems not to be trying to do so.

    See https://stackoverflow.com/questions/25238110/how-to-properly-close-mappedbytebuffer .

    This memory can, by Java default, grow up to the Heap size limit which means your app memory consumption can easily exceed twice the set maximum heap size and then serving large files stops. Direct buffers memmory can be watched using Mbeans (java.nio:name=direct,type=BufferPool MemoryUsed) in jconsole.

    As noted in org.http-kit.HttpUtils.java source in comment on line 111: // serving file is better be done by Nginx

    Or in this scenario, Undertow can be recommended.

    pull-requests welcome server 
    opened by kajism 2
  • Basic Project Template (Skeleton)

    Basic Project Template (Skeleton)

    Hi Guys http-kit looks really good ! But after spending the whole day trying to get THE BASICS up and running I had to move on and look somewhere else:

    a bare-min-basic-example or template would go a long way

    1. Basic hello world template (with latest http-kit) all examples online are years out of date
    2. Basic examples + setup how to interact with project: Example: start, stop, debug, repl.

    Is there no up to date project-skeleton somewhere??

    opened by rawoke083 2
Releases(v2.6.0)

  • v2.6.0(Jun 13, 2022) 

    [http-kit "2.6.0"]

    Non-breaking maintenance release with some fixes and minor features See here recommended steps when updating any Clojure/Script dependencies.

    Identical to v2.6.0-RC1.

    Changes since 2.5.3

    • [#476] [Server] Optimization: change buildRequestMap to create a PersistentHashMap directly (@bsless)

    New since 2.5.3

    • [#471 #472] [Client] Add option to not automatically add Accept-Content header (@MarcoNicolodi)

    Fixes since 2.5.3

    • [#469 #489] [Client] Properly unrecycle req when kept-alive conn wasn't able to be reused (@xwang1498)
    • [#475 #477] [Graal] Add --initialize-at-run-time to config to stop GRAAL builds failing (@askonomm)
    • [#482 #483] [Client] Fix java version parsing for JDK 17 (@pmonks)
    • [#401 #481] [Client] mark Request as connected when reusing keepalive (@xwang1498)

    Everything since 2.6.0-alpha1

    • [#469 #489] [Fix] [Client] Properly unrecycle req when kept-alive conn wasn't able to be reused (@xwang1498)
    Source code(tar.gz)
    Source code(zip)

  • v2.6.0-RC1(May 28, 2022) 

    [http-kit "2.6.0-RC1"]

    Non-breaking maintenance release with some fixes and minor features See here recommended steps when updating any Clojure/Script dependencies.

    Changes since 2.5.3

    • [#476] [Server] Optimization: change buildRequestMap to create a PersistentHashMap directly (@bsless)

    New since 2.5.3

    • [#471 #472] [Client] Add option to not automatically add Accept-Content header (@MarcoNicolodi)

    Fixes since 2.5.3

    • [#469 #489] [Client] Properly unrecycle req when kept-alive conn wasn't able to be reused (@xwang1498)
    • [#475 #477] [Graal] Add --initialize-at-run-time to config to stop GRAAL builds failing (@askonomm)
    • [#482 #483] [Client] Fix java version parsing for JDK 17 (@pmonks)
    • [#401 #481] [Client] mark Request as connected when reusing keepalive (@xwang1498)

    Everything since 2.6.0-alpha1

    • [#469 #489] [Fix] [Client] Properly unrecycle req when kept-alive conn wasn't able to be reused (@xwang1498)
    Source code(tar.gz)
    Source code(zip)

  • v2.6.0-alpha1(Oct 16, 2021) 

    [http-kit "2.6.0-alpha1"]

    Non-breaking maintenance release with some fixes and minor features See here recommended steps when updating any Clojure/Script dependencies.

    Changes since 2.5.3

    • [#476] [Server] Optimization: change buildRequestMap to create a PersistentHashMap directly (@bsless)

    New since 2.5.3

    • [#471 #472] [Client] Add option to not automatically add Accept-Content header (@MarcoNicolodi)

    Fixes since 2.5.3

    • [#475 #477] [Graal] Add --initialize-at-run-time to config to stop GRAAL builds failing (@askonomm)
    • [#482 #483] [Client] Fix java version parsing for JDK 17 (@pmonks)
    • [#401 #481] [Client] mark Request as connected when reusing keepalive (@xwang1498)
    Source code(tar.gz)
    Source code(zip)

  • v2.5.3(Feb 21, 2021) 

    [http-kit "2.5.3"]

    Non-breaking hotfix release. See here recommended steps when updating any Clojure/Script dependencies.

    Fixes since 2.5.2

    • [#462 #437] Fix project.clj compiler option to support older JVMs (e.g. Java 8)
    Source code(tar.gz)
    Source code(zip)

  • v2.5.2(Feb 19, 2021)

    v2.5.2 (2021 Feb 19)

    [http-kit "2.5.2"]

    Non-breaking hotfix release. See here recommended steps when updating any Clojure/Script dependencies.

    Fixes since 2.5.1

    • [#457 #456] [Client] Fix race condition in clientContext initialization (@bsless)
    Source code(tar.gz)
    Source code(zip)

  • v2.5.1(Jan 14, 2021) 

    [http-kit "2.5.1"]

    Non-breaking hotfix release. See here recommended steps when updating any Clojure/Script dependencies.

    Fixes since 2.5.0

    • [#455] [Client] Fix Java version parsing used to set default client hostname-verification? option (@aiba)
    Source code(tar.gz)
    Source code(zip)

  • v2.5.0(Sep 18, 2020) 

    [http-kit "2.5.0"]

    Bumps minimum JVM version from 1.6 to 1.7. Should otherwise be non-breaking.
    See here recommended steps when updating any Clojure/Script dependencies.

    Identical to v2.5.0-RC1.

    Changes since 2.4.0

    • BREAKING: bump minimum JVM version from 1.6 to 1.7
    • [#438 #439][Server] Stop using sun.misc.Unsafe (@kirked)

    New since 2.4.0

    • [#434][Client] GraalVM Native Image Compatibility: move SSL initialisation to constructor (@alekcz)
    • [#433 #432 #129] [Server] Configurable server header (@barkanido)
    • [#441][Server] Add 1-arity server-stop!

    Fixes since 2.4.0

    • [#429] Fix flaky server-status tests
    • [Server][Tests] Fix lint issue with newer JDKs
    Source code(tar.gz)
    Source code(zip)

  • v2.5.0-RC1(Sep 10, 2020) 

    [http-kit "2.5.0-RC1"]

    Bumps minimum JVM version from 1.6 to 1.7. Should otherwise be non-breaking. See here for recommended steps when updating any Clojure/Script dependencies.

    Changes since 2.4.0

    • BREAKING: bump minimum JVM version from 1.6 to 1.7
    • [#438 #439][Server] Stop using sun.misc.Unsafe (@kirked)

    New since 2.4.0

    • [#434][Client] GraalVM Native Image Compatibility: move SSL initialisation to constructor (@alekcz)
    • [#433 #432 #129] [Server] Configurable server header (@barkanido)
    • [#441][Server] Add 1-arity server-stop!

    Fixes since 2.4.0

    • [#429] Fix flaky server-status tests
    • [Server][Tests] Fix lint issue with newer JDKs
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0(Jul 30, 2020) 

    [http-kit "2.4.0"]

    Identical to 2.4.0-RC1, 2.4.0-beta1.

    Upgrade from 2.3.x should be non-breaking, but please evaluate before using in production (and please report any problems!).

    [Server] DEPRECATION NOTICE: with-channel macro has been deprecated due to possible race conditions [#318]. Please prefer new as-channel fn instead. Migration is straightforward; please see as-channel docstring for usage info.

    Changes since 2.3.0

    • [#318][#391] [Server] DEPRECATE with-channel, add as-channel
    • [#399][Server] Graceful Shutdown (@glenjamin)
    • [#427] [Client] Improve performance of prepare-request-headers (@bsless)

    New since 2.3.0

    • [#412 #383 #388] Java 11 support (@ryfow, @RokLenarcic)
    • [#426 #422 #393 #334 #187] [Client] Add a drop-in SNI-capable client (@fpischedda, @jimpil)
    • [#422] [Client] Provide a dynamic var to override default client (@fpischedda)
    • [#318][#391] [Server] as-channel: add :init hook
    • [Server] Optional new return value for run-server, new fns: server-port, server-status, server-shutdown!
    • [#429 #186] [Server] server-stop! now returns a promise (@alekcz, @ptaoussanis)
    • [#395] [Server] Add keywords to cover missing WebSocket status codes (@daviesian)
    • [#374] [Client] Allow specification of local address when making requests (@snoe)
    • [#379] [Server] Support byte[] responses (@ikitommi)
    • [#389] [Client] Make query-string public (@kirked)
    • [#400 #402] [Client] Add :none coercion option to return byte-array (@ethpran)
    • [#403 #415] [Client] Add error message when no location header is present (@BadAlgorithm)

    Fixes since 2.3.0

    • [#410 #419] [Server] Special-case the parsing for ipv6, if the host header starts with [ (@blak3mill3r)
    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0-RC1(Jul 25, 2020)

  • v2.4.0-beta1(Jul 21, 2020) 

    [http-kit "2.4.0-beta1"]

    Should be non-breaking but as usual, please evaluate before using in production (and please report any problems!).

    Items new since 2.4.0-alpha6 prefixed with ++.

    Changes since 2.3.0

    • [Server][Experimental] Deprecate with-channel, add as-channel
    • [#399][Server] Graceful Shutdown (@glenjamin)
    • ++ [#427] [Client] Improve performance of prepare-request-headers (@bsless)

    New since 2.3.0

    • [#412 #383 #388] Java 11 support (@ryfow, @RokLenarcic)
    • [#426 #422 #393 #334 #187] [Client] Add a drop-in SNI-capable client (@fpischedda, @jimpil)
    • [#422] [Client] Provide a dynamic var to override default client (@fpischedda)
    • ++ [#318][#391] [Server] as-channel: add :init hook
    • ++ [Server] New return value for run-server, new fns: server-port, server-status, server-shutdown!
    • ++ [#429 #186] [Server] server-stop! now returns a promise (@alekcz, @ptaoussanis)
    • [#395] [Server] Add keywords to cover missing WebSocket status codes (@daviesian)
    • [#374] [Client] Allow specification of local address when making requests (@snoe)
    • [#379] [Server] Support byte[] responses (@ikitommi)
    • [#389] [Client] Make query-string public (@kirked)
    • [#400 #402] [Client] Add :none coercion option to return byte-array (@ethpran)
    • [#403 #415] [Client] Add error message when no location header is present (@BadAlgorithm)

    Fixes since 2.3.0

    • [#410 #419] [Server] Special-case the parsing for ipv6, if the host header starts with [ (@blak3mill3r)
    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0-alpha6(Feb 15, 2020) 

    [http-kit "2.4.0-alpha6"]

    As usual, please evaluate before using in production (and please report any problems!).

    Changes since 2.3.0

    • [#318 #391][Server][Experimental] Deprecate with-channel, add as-channel
    • [#399][Server] Graceful Shutdown (@glenjamin)

    New since 2.3.0

    • [#412 #383 #388] Java 11 support (@ryfow, @RokLenarcic)
    • [#426 #422 #393 #334 #187] [Client] Add a drop-in SNI-capable client (@fpischedda, @jimpil)
    • [#422] [Client] Provide a dynamic var to override default client (@fpischedda)
    • [#395] [Server] Add keywords to cover missing WebSocket status codes (@daviesian)
    • [#374] [Client] Allow specification of local address when making requests (@snoe)
    • [#379] [Server] Support byte[] responses (@ikitommi)
    • [#389] [Client] Make query-string public (@kirked)
    • [#400 #402] [Client] Add :none coercion option to return byte-array (@ethpran)
    • [#403 #415] [Client] Add error message when no location header is present (@BadAlgorithm)

    Fixes since 2.3.0

    • [#410 #419] [Server] Special-case the parsing for ipv6, if the host header starts with [ (@blak3mill3r)
    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0-alpha3(Jan 19, 2019) 

    [http-kit "2.4.0-alpha3"]

    As usual, please evaluate before using in production (and please report any problems!).

    Changes

    • [#391 #318 #46] [Server] BREAKING: ensure WS on-receive is ready before first message arrives (@huahaiy)

    New stuff

    • [#383 #388] Java 11 support (@ryfow)
    • [#374] [Client] Allow specification of local address when making requests (@snoe)
    • [#379] [Server] Support byte[] responses (@ikitommi)

    Fixes

    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0-alpha2(Dec 2, 2018) 

    [http-kit "2.4.0-alpha2"]

    As usual, please evaluate before using in production (and please report any problems!).

    New stuff

    • [#383 #388] Java 11 support (@ryfow)
    • [#374] [Client] Allow specification of local address when making requests (@snoe)
    • [#379] [Server] Support byte[] responses (@ikitommi)

    Fixes

    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.4.0-alpha1(Dec 2, 2018) 

    [http-kit "2.4.0-alpha1"]

    As usual, please evaluate before using in production (and please report any problems!).

    New stuff

    • [#383 #388] Java 11 support (@ryfow)

    Fixes

    • [#384] [Server] Fix typo in run-server doc-string (@dsdolzhenko)
    Source code(tar.gz)
    Source code(zip)

  • v2.3.0(Apr 21, 2018) 

    [http-kit "2.3.0"]

    This is a major release that should be non-breaking but may require testing. Please evaluate before using in production (and please report any problems!).

    A big thank you to all the contributors for this release!

    - Peter Taoussanis (@ptaoussanis)

    Listed changes are relative to 2.2.0:

    New stuff

    • [#345 #372] Client: add deadlock-guard for callbacks (@Chouser), enabled by default (could be BREAKING, disable using :deadlock-guard? option).
    • [#315] Client: now have separate :connect-timeout and :idle-timeout opts (@kmate)
    • [#329] Client: support numbers in multipart messages, and throw on unkown multipart params types (@dmichulke)
    • [#303] Client: replace :proxy-host, :proxy-port -> :proxy-url (@taso42)
    • [#335] Client: allow custom SSLEngine config, make way for fixing #187 (@kumarshantanu)
    • [#323 #333] Client, server: add metrics/logging instrumentation (@kumarshantanu)
    • [#307 #231] Server: add :worker-pool opt (@kaibra)
    • [#309 #310] Server: add missing 'MKCOL' http method enum (@zilti)
    • [#300] Server: add getCount method to BytesInputStream (@MysteryMachine)

    General improvements

    • [#330] Server: don't override Date header if it's been set by application (@ryfow)
    • [#341 #196] Server: increase max-line default value to conform to nginx defaults (@Kjir)
    • Client: deref default-client ONLY-when client not specified (@kumarshantanu)
    • [#353] Tidy up some tests (@glenford)

    Fixes

    • [#332 #322] Server: do not respond to unsolicited pong frames (@mikkosuonio)
    • [#319] Server: fix the 'Close received after close' issue for WS implementation (@zhming0)
    • [#356 #370] Client, server: fix base64-encoder for Java 9 (@claj @benalbrecht)
    • [#361 #362] Client: fix bug in parsing logic for chunked responses (@rkaippully)
    Source code(tar.gz)
    Source code(zip)

  • v2.3.0-RC1(Apr 9, 2018)

  • 2.3.0-beta2(Mar 17, 2018)

  • 2.3.0-beta1(Mar 11, 2018) 

    [http-kit "2.3.0-beta1"]

    This is a major feature and maintenance release. Please test carefully and report any bugs!

    Changes since 2.2.0:

    New stuff

    • [#315] Client: now have separate :connect-timeout and :idle-timeout opts (@kmate)
    • [#307 #231] Server: add :worker-pool opt (@kaibra)
    • [#309 #310] Server: add missing 'MKCOL' http method enum (@zilti)
    • [#329] Client: support numbers in multipart messages, and throw on unkown multipart params types (@dmichulke)
    • [#300] Server: add getCount method to BytesInputStream (@MysteryMachine)
    • [#335] Make way for fixing #187 (@kumarshantanu)
    • [#323 333] Metrics/logging instrumentation (@kumarshantanu)

    General improvements

    • [#330] Server: don't override Date header if it's been set by application (@ryfow)
    • [#303] Client: replace :proxy-host, :proxy-port -> :proxy-url (@taso42)
    • [#341 #196] Server: increase max-line default value to conform to nginx defaults (@Kjir)
    • Client: deref default-client ONLY-when client not specified (@kumarshantanu)

    Fixes

    • [#332 #322] Server: do not respond to unsolicited pong frames (@mikkosuonio)
    • [#319] Server: fix the 'Close received after close' issue for WS implementation (@zhming0)
    • [#361 #362] Client: fix bug in parsing logic for chunked responses (@rkaippully)
    Source code(tar.gz)
    Source code(zip)

  • 2.3.0-alpha5(Feb 2, 2018) 

    [http-kit "2.3.0-alpha5"]

    This is a minor hotfix release. Please test carefully and report any bugs!

    Hotfix: [#361 #362] Client: fix bug in parsing logic for chunked responses (@rkaippully)

    Source code(tar.gz)
    Source code(zip)

  • 2.3.0-alpha4(Sep 3, 2017) 

    [http-kit "2.3.0-alpha4"]

    This is a minor feature release. Please test carefully and report any bugs!

    New stuff

    • [#335] Make way for fixing #187 (@kumarshantanu)
    • [#323 #333] Metrics/logging instrumentation (@kumarshantanu)

    General improvements

    • [#341 #196] Server: increase max-line default value to conform to nginx defaults (@Kjir)
    • Client: deref default-client ONLY-when client not specified (@kumarshantanu)
    Source code(tar.gz)
    Source code(zip)

  • 2.3.0-alpha2(Apr 16, 2017) 

    [http-kit "2.3.0-alpha2"]

    This is a major feature and maintenance release. Please test carefully and report any bugs!

    New stuff

    • [#315] Client: now have separate :connect-timeout and :idle-timeout opts (@kmate)
    • [#307 #231] Server: add :worker-pool opt (@kaibra)
    • [#309 #310] Server: add missing 'MKCOL' http method enum (@zilti)
    • [#329] Client: support numbers in multipart messages, and throw on unkown multipart params types (@dmichulke)
    • [#300] Server: add getCount method to BytesInputStream (@MysteryMachine)

    General improvements

    • [#330] Server: don't override Date header if it's been set by application (@ryfow)
    • [#303] Client: replace :proxy-host, :proxy-port -> :proxy-url (@taso42)

    Fixes

    • [#332 #322] Server: do not respond to unsolicited pong frames (@mikkosuonio)
    • [#319] Server: fix the 'Close received after close' issue for WS implementation (@zhming0)
    Source code(tar.gz)
    Source code(zip)

  • 2.2.0(Jul 12, 2016) 

    [http-kit "2.2.0"]

    This is the big one; the first stable http-kit release published by contributors!

    This should be a non-breaking upgrade from 2.1.19 but, as always, please report any unexpected problems. Thanks!

    - Peter Taoussanis (@ptaoussanis)

    Changes since 2.1.19 (the last stable release published by @shenfeng)

    New stuff

    • [#236] Server: add proxy protocol support (@tendant)
    • [#283] Server: allow overwriting "Server" response header (@skazhy)
    • [#285] Server: add send-websocket-handshake! util for pre-handshake auth, etc.
    • [#201] Client: add support for optional unsafe redirects (@dzaharee)
    • [#275] Client: add proxy support (@davidkazlauskas, @jbristow)
    • [#280 #281 #291] Client: allow https requests through proxy, tunneling (@jshaw86, @jbristow)
    • [#297] Client: allow multipart entity to support byte arrays (@vincentjames501)
    • [#297] Client: allow setting multipart content type (@vincentjames501)
    • [#293] Client: add max connections support (@ryfow)

    General improvements

    • [#130] Server: can now respond to HTTP_1.1/Expect: 100-continue headers (@valentini)
    • [#216] Server: optimization, remove an unnecessary operation (@songsd)
    • [#217] Client: more accurate timeout handling (@mbarbon)
    • [#234] Client: catch Throwable when delivering client response (@msassak)
    • [#185] Client: do not set client mode on SSLEngine if already set (@izarov)
    • [#261 #203] Client: updated documentation on request function (@javahippie)
    • [#274 #272] Client: make HttpClient class non-final (@kumarshantanu)
    • [#266] Project: fix #189 - include Java source files in the JAR (@kumarshantanu)

    Fixes

    • [#259 #227] Server: reset decoder after starting the close handshake for the websocket server (@venantius)
    • [#258 #148] Server: remind the selector to wake up (@venantius)
    • [#248] Server: correctly reset fragmentedOpCode on WS frame completion (@daviesian)
    • [#250] Server: omit invalid headers and prevent possible exceptions (e.g., NullPointerException) (@Chienlung)
    • [#255] Server: fixed empty sequence NPE, added test (@leblowl)
    • [#264 #219] Client: set SO_KEEPALIVE and TCP_NODELAY for client socket (@jruthe)
    • [#264 #209] Client: clear query and form params on 301-303 redirects (@jruthe)
    • [#254] Server: byteBuffer is 0-based (@Thingographist)
    • [#190] Server: transfer-Encoding is only supported in HTTP Version 1.1 (@jenshaase)
    Source code(tar.gz)
    Source code(zip)

  • 2.2.2-beta1(Jun 21, 2016) 

    [http-kit "2.2.0-beta1"]

    Feature freeze: this is expected to be the final release before v2.2.0-RC1.

    Changes since *2.2.0-alpha2*:

    New stuff

    • [#297] Client: allow multipart entity to support byte arrays (@vincentjames501)
    • [#297] Client: allow setting multipart content type (@vincentjames501)
    • [#293] Client: add max connections support (@ryfow)
    Source code(tar.gz)
    Source code(zip)

  • 2.2.0-alpha2(Jun 8, 2016) 

    [http-kit "2.2.0-alpha2"]

    This should be a non-breaking upgrade from 2.2.0-alpha1 but please evaluate before using in production.

    Thank you to all contributors for this release!

    - Peter Taoussanis (@ptaoussanis)

    Listed changes are relative to 2.2.0-alpha1:

    New stuff

    • [#275] Client: add proxy support (@davidkazlauskas, @jbristow)
    • [#280 #281 #291] Client: allow https requests through proxy, tunneling (@jshaw86, @jbristow)
    • [#283] Server: allow overwriting "Server" response header (@skazhy)

    General improvements

    • [#274 #272] Make HttpClient class non-final (@kumarshantanu)

    Fixes

    • [#190] Transfer-Encoding is only supported in HTTP Version 1.1 (@jenshaase)
    Source code(tar.gz)
    Source code(zip)

  • 2.2.0-alpha1(Mar 3, 2016) 

    [http-kit "2.2.0-alpha1"]

    This is a major release that should be non-breaking but may require testing. Please evaluate before using in production (and please report any problems!).

    A big thank you to all the contributors for this release!

    - Peter Taoussanis (@ptaoussanis)

    Listed changes are relative to last stable release (2.1.19)

    New stuff

    • [#236] Server enhancement: add proxy protocol support (@tendant)
    • [#201] Client now supports optional unsafe redirects (@dzaharee)

    General improvements

    • [#130] Server can now respond to HTTP_1.1/Expect: 100-continue headers (@valentini)
    • [#217] More accurate timeout handling (@mbarbon)
    • [#234] Catch Throwable when delivering client response (@msassak)
    • [#185] Do not set client mode on SSLEngine if already set (@izarov)
    • [#261 #203] Updated documentation on request function (@javahippie)
    • [#266] Fix #189 - include Java source files in the JAR (@kumarshantanu)
    • [#216] Server optimization: remove an unnecessary operation (@songsd)

    Bug fixes

    • [#259 #227] Reset decoder after starting the close handshake for the websocket server (@venantius)
    • [#258 #148] Remind the selector to wake up (@venantius)
    • [#248] Correctly reset fragmentedOpCode on WS frame completion (@daviesian)
    • [#250] Omit invalid headers and prevent possible exceptions (e.g., NullPointerException) (@Chienlung)
    • [#255] Fixed empty sequence NPE, added test (@leblowl)
    • [#264 #219] Set SO_KEEPALIVE and TCP_NODELAY for client socket (@jruthe)
    • [#264 #209] Clear query and form params on 301-303 redirects (@jruthe)
    • [#254] ByteBuffer is 0-based (@Thingographist)
    Source code(tar.gz)
    Source code(zip)

  • 2.1.21-alpha2(Dec 12, 2015) 

    [http-kit "2.1.21-alpha2"]

    == 2.1.21-alpha1 (Clojars upload error)

    HTTP Server:

    • [#217] More accurate timeout handling (@mbarbon)
    • [#130] Server can now respond to HTTP_1.1/Expect : 100-continue header once per request (@valentini)

    HTTP Client:

    • [#201] Client: option to keep "unsafe" method on redirect (@dzaharee)
    Source code(tar.gz)
    Source code(zip)

  • 2.1.20-fork(Dec 12, 2015) 

    [com.taoensso.forks/http-kit "2.1.20"]

    This release was a temporary fork

    HTTP Server:

    1. #86 Allow run-server being called without any opts (@djui)
    2. #185 Do not set client mode on SSLEngine if already set (@izarov)
    3. #234 Catch Throwable when delivering response (@msassak)
    4. #239 HTTP client: keep form params in multipart requests (@skazhy)

    HTTP Client: No changes

    Source code(tar.gz)
    Source code(zip)
Owner
HTTP Client/Server for Clojure
HTTP Client/Server for Clojure
GitHub
A Java event based WebSocket and HTTP server

Webbit - A Java event based WebSocket and HTTP server Getting it Prebuilt JARs are available from the central Maven repository or the Sonatype Maven r

null 808 Jan 3, 2023
A high-level and lightweight HTTP client framework for Java. it makes sending HTTP requests in Java easier.

A high-level and lightweight HTTP client framework for Java. it makes sending HTTP requests in Java easier.

dromara 1.2k Jan 8, 2023
Google HTTP Client Library for Java

Google HTTP Client Library for Java Description Written by Google, the Google HTTP Client Library for Java is a flexible, efficient, and powerful Java

Google APIs 1.3k Jan 4, 2023
Unirest in Java: Simplified, lightweight HTTP client library.

Unirest for Java Install With Maven: <!-- Pull in as a traditional dependency --> <dependency> <groupId>com.konghq</groupId> <artifactId>unire

Kong 2.4k Jan 5, 2023
Unirest in Java: Simplified, lightweight HTTP client library.

Unirest for Java Install With Maven: <!-- Pull in as a traditional dependency --> <dependency> <groupId>com.konghq</groupId> <artifactId>unire

Kong 2.4k Jan 5, 2023
Square’s meticulous HTTP client for the JVM, Android, and GraalVM.

OkHttp See the project website for documentation and APIs. HTTP is the way modern applications network. It’s how we exchange data & media. Doing HTTP

Square 43.4k Jan 5, 2023
Ribbon is a Inter Process Communication (remote procedure calls) library with built in software load balancers. The primary usage model involves REST calls with various serialization scheme support.

Ribbon Ribbon is a client side IPC library that is battle-tested in cloud. It provides the following features Load balancing Fault tolerance Multiple

Netflix, Inc. 4.4k Jan 1, 2023
Tiny, easily embeddable HTTP server in Java.

NanoHTTPD – a tiny web server in Java NanoHTTPD is a light-weight HTTP server designed for embedding in other applications, released under a Modified

NanoHttpd 6.5k Jan 5, 2023
Attempt is a lightweight component provides declarative retry support for applications, not only but a polling strategy. With Attempt, you can easily poll for something with retry functionality. Non-spring and lightweight applications are friendly for a fewer dependencies.

中文文档 Introduction Attempt is a lightweight component provides declarative retry support for applications, not only but a polling strategy. With Attemp

Jason Lee 3 Oct 11, 2022
Java HTTP Request Library

Http Request A simple convenience library for using a HttpURLConnection to make requests and access the response. This library is available under the

Kevin Sawicki 3.3k Dec 30, 2022
Koios Java Client Library is based on Koios Elastic Query Layer for Cardano Node by Cardano Community Guild Operators

Koios Java Client What is Koios? Koios Java Client Library is based on Koios Elastic Query Layer for Cardano Node by Cardano Community Guild Operators

Dudi Edri 13 Dec 4, 2022
Konas Client de-obfuscated and manually remaped by Gopro336, Perry, and other based people

Konas-Deobf-Remap This project doesent really have a purpose anymore now that the real source code has leaked (this is a higher version tho) Deobfusca

null 52 Dec 13, 2022
Feign makes writing java http clients easier

Feign makes writing java http clients easier Feign is a Java to HTTP client binder inspired by Retrofit, JAXRS-2.0, and WebSocket. Feign's first goal

null 8.5k Dec 30, 2022
⚗️ Lightweight HTTP extensions for Java 11

Methanol A lightweight library that complements java.net.http for a better HTTP experience. Overview Methanol provides useful lightweight HTTP extensi

Moataz Abdelnasser 175 Dec 17, 2022
Feign makes writing java http clients easier

Feign makes writing java http clients easier Feign is a Java to HTTP client binder inspired by Retrofit, JAXRS-2.0, and WebSocket. Feign's first goal

null 8.5k Jan 1, 2023
Share the chat messages across Minecraft Servers via HTTP backend powered by Spring Boot, this is the backend part of the project.

InterconnectedChat-Backend Share the chat messages across Minecraft Servers via HTTP backend powered by Spring Boot, this is the backend part of the p

贺兰星辰 3 Oct 6, 2021
Fast_Responder is a service that lets you quickly create an Http request responder

Fast_Responder is a service that lets you quickly create an Http request responder. The transponder can receive any request path configured and determine the request parameters according to your configuration to return different results. In addition to processing requests, the transponder can also make Http requests to any request address based on the latency, request headers, and parameters you configure. In essence, fast_responder is a dynamic mock service.

null 8 Jan 26, 2022
httpx - CLI to run HTTP file

httpx: CLI for run http file httpx is a CLI to execute requests from JetBrains Http File. How to install? Mac : brew install httpx-sh/tap/httpx Other

httpx 105 Dec 15, 2022
Client-side response routing for Spring

Riptide: A next generation HTTP client Riptide noun, /ˈrɪp.taɪd/: strong flow of water away from the shore Riptide is a library that implements client

Zalando SE 235 Jan 3, 2023