Skip to content

Have a CookieJar #1235

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

Closed
fangqiao opened this issue Aug 23, 2016 · 6 comments
Closed

Have a CookieJar #1235

fangqiao opened this issue Aug 23, 2016 · 6 comments

Comments

@fangqiao
Copy link

Hi,

I am using this lib for testing a custom REST server based on Netty 4.1. 4, the latest, using Scala.

I need to test that cookie has been set correctly at sever side and can be parsed correct on next request.

I used a single DefaultAsyncHttpClient object to submit the first round of request and it received server set cookies successfully.

val httpClient = new  DefaultAsyncHttpClient()

  val request : Request = (new RequestBuilder("POST")).
    setUrl("http://127.0.0.1:9090/login").
    setBody(json).
    build()

  val future : Future[Response] = httpClient.executeRequest(request)


  val response: Response = future.get()

  response.getStatusCode should equal (200)
  val cookies = response.getCookies 

The cookies from server were correctly returned.

Then I used the same DefaultAsyncHttpClient object to submit another request. I supposed the cookies be sent to server automatically. But the netty server was never able to get the cookies from the requests.

Then i tried in the next request by explicitly setting cookies.
val request2: Request = (new RequestBuilder("GET")).
setUrl("http://127.0.0.1:9090/developer").
setCookies(cookies).
build()

This time the netty server can parse the cookies correctly.

I am wondering if it is by design that DefaultAsyncHttpClient will not send server side cookies in next round of request.

If so, I suggest to add the support to coming versions.

If not, what's the correct way to use this feature, which is very useful for my case.

Thanks

@slandelle
Copy link
Contributor

I am wondering if it is by design that DefaultAsyncHttpClient will not send server side cookies in next round of request.

No, AHC doesn't provide a cookie jar.

If so, I suggest to add the support to coming versions.

Contribs welcome

If not, what's the correct way to use this feature, which is very useful for my case.

You have the responses where you can fetch the Set-Cookie header, fetch those and use them to craft the next requests.

@fangqiao
Copy link
Author

Thanks for the answers.

You have the responses where you can fetch the Set-Cookie header, fetch those and use them to craft the next requests.

That is exactly what i am doing now.

Maybe as interim solution, add a line to API doc or github homepage?

@slandelle slandelle changed the title Cookie set by http server not sent back in next HTTP requests with the same DefaultAsyncHttpClient Have a CookieJar Oct 12, 2016
Diagoras added a commit to Diagoras/async-http-client that referenced this issue Nov 27, 2016
…, now handling cookies as a Set instead of List
@slandelle
Copy link
Contributor

No contrib so far. Closing for now.

@slandelle
Copy link
Contributor

Note for potential contributor: you can have a look at https://github.com/gatling/gatling/blob/master/gatling-http/src/main/scala/io/gatling/http/cookie/CookieJar.scala for an example. Main difference is AHC would need a thread safe implementation (most likely ConcurrentHashMap based).

@unoexperto
Copy link
Contributor

@slandelle Could you please tell me what aspect exactly of implementation of CookieJar use provided above in Diagoras@96747f9 you consider incorrect ?

@slandelle
Copy link
Contributor

Sadly, all of it: it doesn't implement anything from the RFC6265 spec, such as domain and path matching.

@slandelle slandelle reopened this Jan 11, 2018
@slandelle slandelle added this to the 2.1.0 milestone Jan 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants