[PATCH] Match against newer curl.

[PATCH] Match against newer curl.

[Lin Jen-Shin]

My curl 7.32.0 would actually print 400 Bad Request
Hope this would make it match against newer or older curl.
---
 t/t0045-client_max_header_size.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t0045-client_max_header_size.sh b/t/t0045-client_max_header_size.sh
index cd8f1fe..320fe0c 100755
--- a/t/t0045-client_max_header_size.sh
+++ b/t/t0045-client_max_header_size.sh
@@ -60,7 +60,7 @@ t_begin "smallest HTTP/0.9 request works right" && {
 
 t_begin "HTTP/1.1 request fails" && {
 	curl -vsSf http://$listen/ > $tmp 2>&1 && die "unexpected curl success"
-	grep '400$' $tmp
+	grep '400\( Bad Request\)\?$' $tmp
 }
 
 t_begin "increase client_max_header_size on reload" && {
-- 
1.8.4

_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: [PATCH] Match against newer curl.

[Eric Wong]

Lin Jen-Shin <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
> My curl 7.32.0 would actually print 400 Bad Request
> Hope this would make it match against newer or older curl.
> ---
>  t/t0045-client_max_header_size.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t0045-client_max_header_size.sh b/t/t0045-client_max_header_size.sh
> index cd8f1fe..320fe0c 100755
> --- a/t/t0045-client_max_header_size.sh
> +++ b/t/t0045-client_max_header_size.sh
> @@ -60,7 +60,7 @@ t_begin "smallest HTTP/0.9 request works right" && {
>  
>  t_begin "HTTP/1.1 request fails" && {
>  	curl -vsSf http://$listen/ > $tmp 2>&1 && die "unexpected curl success"
> -	grep '400$' $tmp
> +	grep '400\( Bad Request\)\?$' $tmp

I think thse cases should just use "--write-out %{http_code}" instead.
Theres probably a bunch of places where we should be doing this, really.
--write-out has been around for at least 10 years, so I think it's safe
to use.

Also, I notice this got combined into your EventMachineThread* patch.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: [PATCH] Match against newer curl.

[Lin Jen-Shin (godfat)]

On Wed, Sep 25, 2013 at 9:46 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> Lin Jen-Shin <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
>> My curl 7.32.0 would actually print 400 Bad Request
>> Hope this would make it match against newer or older curl.
>> ---
>>  t/t0045-client_max_header_size.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t0045-client_max_header_size.sh b/t/t0045-client_max_header_size.sh
>> index cd8f1fe..320fe0c 100755
>> --- a/t/t0045-client_max_header_size.sh
>> +++ b/t/t0045-client_max_header_size.sh
>> @@ -60,7 +60,7 @@ t_begin "smallest HTTP/0.9 request works right" && {
>>
>>  t_begin "HTTP/1.1 request fails" && {
>>       curl -vsSf http://$listen/ > $tmp 2>&1 && die "unexpected curl success"
>> -     grep '400$' $tmp
>> +     grep '400\( Bad Request\)\?$' $tmp
>
> I think thse cases should just use "--write-out %{http_code}" instead.
> Theres probably a bunch of places where we should be doing this, really.
> --write-out has been around for at least 10 years, so I think it's safe
> to use.

Great. Just checked it and it worked. What about introducing
http_status() utility function in this case? I could do this.

> Also, I notice this got combined into your EventMachineThread* patch.

Yeah, I haven't written any document as the other concurrency models,
either. Since it seems I did something wrong, and the tests could not
pass completely for some reasons, I chose to send the patch first
anyway :(

Sorry I should have mentioned this.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: [PATCH] Match against newer curl.

[Eric Wong]

"Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Sep 25, 2013 at 9:46 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> > I think thse cases should just use "--write-out %{http_code}" instead.
> > Theres probably a bunch of places where we should be doing this, really.
> > --write-out has been around for at least 10 years, so I think it's safe
> > to use.
> 
> Great. Just checked it and it worked. What about introducing
> http_status() utility function in this case? I could do this.

Yes, that would be great.  Thanks!

> > Also, I notice this got combined into your EventMachineThread* patch.
> 
> Yeah, I haven't written any document as the other concurrency models,
> either. Since it seems I did something wrong, and the tests could not
> pass completely for some reasons, I chose to send the patch first
> anyway :(
> 
> Sorry I should have mentioned this.

No worries.  I might not have time to look at the failures for a while.
Based on our past discussions, I'm not sure if EM is worth continuing
supporting (especially not for threads).

So I probably won't dedicate much time to it myself unless you can fix
all the problems with it.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: [PATCH] Match against newer curl.

[Lin Jen-Shin (godfat)]

On Thu, Sep 26, 2013 at 1:28 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> No worries.  I might not have time to look at the failures for a while.
> Based on our past discussions, I'm not sure if EM is worth continuing
> supporting (especially not for threads).
>
> So I probably won't dedicate much time to it myself unless you can fix
> all the problems with it.

I see. Then maybe I won't really put too much effort on it any further
as well... Since external gems could also work, and I can't really tell
what's wrong with EventMachineThreadSpawn. It might not really
make sense to have only EventMachineThreadDefer but not the
others, either...
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying