Tagged a new version before starting to break API compatibility for the upcoming big release. This version contains a few fixes that do not break compatibility. I do not plan to make another release before 0.8.
Changes are:
* Add hello_world, rest_hello_world, chunked_hello_world,
echo_get, echo_post and static examples.
* Add support for the "Expect: 100-continue" header.
* Keep the original 'Host' header value instead of modifying it.
* Fix use of parsed headers cache.
* REST: fix the matching of charsets.
* REST: allow <<"type/subtype">> format for content_types_accepted.
* Improve typespecs.
I urge everyone to get out of master for a little while because the switch to Ranch will break your project until you make the necessary changes.
> Tagged a new version before starting to break API compatibility for the upcoming big release. This version contains a few fixes that do not break compatibility. I do not plan to make another release before 0.8.
Nope that one comes after 0.8. It breaks API compatibility because the point is most importantly to remove the inconsistencies of decode_packet like the header name being either atom() or binary() and such.
> Congrats for this new release.
> Did it include the parsing of HTTP headers without the decode_packet call?
> Regards,
> Zabrane
> On Aug 8, 2012, at 2:00 PM, Loïc Hoguin wrote:
>> Hello,
>> Tagged a new version before starting to break API compatibility for the upcoming big release. This version contains a few fixes that do not break compatibility. I do not plan to make another release before 0.8.
On Wed, Aug 8, 2012 at 6:14 PM, Loïc Hoguin <es...@ninenines.eu> wrote: > Nope that one comes after 0.8. It breaks API compatibility because the point > is most importantly to remove the inconsistencies of decode_packet like the > header name being either atom() or binary() and such.
> On 08/08/2012 04:10 PM, Zabrane Mickael wrote:
>> Hi Loïc,
>> Congrats for this new release. >> Did it include the parsing of HTTP headers without the decode_packet call?
>> Regards, >> Zabrane
>> On Aug 8, 2012, at 2:00 PM, Loïc Hoguin wrote:
>>> Hello,
>>> Tagged a new version before starting to break API compatibility for the >>> upcoming big release. This version contains a few fixes that do not break >>> compatibility. I do not plan to make another release before 0.8.
>>> * Add support for the "Expect: 100-continue" header.
>>> * Keep the original 'Host' header value instead of modifying it.
>>> * Fix use of parsed headers cache.
>>> * REST: fix the matching of charsets.
>>> * REST: allow <<"type/subtype">> format for content_types_accepted.
>>> * Improve typespecs.
>>> I urge everyone to get out of master for a little while because the >>> switch to Ranch will break your project until you make the necessary >>> changes.
decode_packet would be a lot faster if it wasn't doing most things it's actually doing that make it more problematic for me to handle requests. Problems include:
* using both atoms and binaries for header names * for binary header names, changing the case but only for name length < 22 characters, and with a weird behavior if it contains "--" * returning tuples for everything (forces me to handle all the different errors at the same level, and makes it harder to read) * not allowing me to fail early (see previous)
I can simplify the code a lot by not using it, all without sacrificing performance because I can still use binary BIFs instead. The only thing that requires a little Erlang code is parsing the request line.
> What is better: rewrite parsing in erlang, either add translation of > atoms to binaries? > Isn't parsing via decode_packet very fast?
> On Wed, Aug 8, 2012 at 6:14 PM, Loïc Hoguin <es...@ninenines.eu> wrote: >> Nope that one comes after 0.8. It breaks API compatibility because the point >> is most importantly to remove the inconsistencies of decode_packet like the >> header name being either atom() or binary() and such.
>> On 08/08/2012 04:10 PM, Zabrane Mickael wrote:
>>> Hi Loïc,
>>> Congrats for this new release. >>> Did it include the parsing of HTTP headers without the decode_packet call?
>>> Regards, >>> Zabrane
>>> On Aug 8, 2012, at 2:00 PM, Loïc Hoguin wrote:
>>>> Hello,
>>>> Tagged a new version before starting to break API compatibility for the >>>> upcoming big release. This version contains a few fixes that do not break >>>> compatibility. I do not plan to make another release before 0.8.
>>>> * Add support for the "Expect: 100-continue" header.
>>>> * Keep the original 'Host' header value instead of modifying it.
>>>> * Fix use of parsed headers cache.
>>>> * REST: fix the matching of charsets.
>>>> * REST: allow <<"type/subtype">> format for content_types_accepted.
>>>> * Improve typespecs.
>>>> I urge everyone to get out of master for a little while because the >>>> switch to Ranch will break your project until you make the necessary >>>> changes.
On Wed, Aug 8, 2012 at 7:39 PM, Loïc Hoguin <es...@ninenines.eu> wrote: > decode_packet would be a lot faster if it wasn't doing most things it's > actually doing that make it more problematic for me to handle requests. > Problems include:
> * using both atoms and binaries for header names > * for binary header names, changing the case but only for name length < 22 > characters, and with a weird behavior if it contains "--" > * returning tuples for everything (forces me to handle all the different > errors at the same level, and makes it harder to read) > * not allowing me to fail early (see previous)
> I can simplify the code a lot by not using it, all without sacrificing > performance because I can still use binary BIFs instead. The only thing that > requires a little Erlang code is parsing the request line.
> On 08/08/2012 04:52 PM, Max Lapshin wrote:
>> What is better: rewrite parsing in erlang, either add translation of >> atoms to binaries? >> Isn't parsing via decode_packet very fast?
>> On Wed, Aug 8, 2012 at 6:14 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
>>> Nope that one comes after 0.8. It breaks API compatibility because the >>> point >>> is most importantly to remove the inconsistencies of decode_packet like >>> the >>> header name being either atom() or binary() and such.
>>> On 08/08/2012 04:10 PM, Zabrane Mickael wrote:
>>>> Hi Loïc,
>>>> Congrats for this new release. >>>> Did it include the parsing of HTTP headers without the decode_packet >>>> call?
>>>> Regards, >>>> Zabrane
>>>> On Aug 8, 2012, at 2:00 PM, Loïc Hoguin wrote:
>>>>> Hello,
>>>>> Tagged a new version before starting to break API compatibility for the >>>>> upcoming big release. This version contains a few fixes that do not >>>>> break >>>>> compatibility. I do not plan to make another release before 0.8.
>>>>> * Add support for the "Expect: 100-continue" header.
>>>>> * Keep the original 'Host' header value instead of modifying it.
>>>>> * Fix use of parsed headers cache.
>>>>> * REST: fix the matching of charsets.
>>>>> * REST: allow <<"type/subtype">> format for content_types_accepted.
>>>>> * Improve typespecs.
>>>>> I urge everyone to get out of master for a little while because the >>>>> switch to Ranch will break your project until you make the necessary >>>>> changes.
> I can simplify the code a lot by not using it, all without sacrificing performance because I can still use binary BIFs instead. The only thing that requires a little Erlang code is parsing the request line.
Compiling lastest Cowboy from github with R15B01 and running Dialyzer, I got this:
cowboy $ make dialyze
Checking whether the PLT .cowboy.plt is up-to-date... yes
Proceeding with analysis...
cowboy_http_protocol.erl:36: Callback info about the cowboy_protocol behaviour is not available
That's something that got added to R15, but if you use it it can't compile on R14, so since we are dropping R14 in the next version we simply waited before adding the callback specs.
On 08/14/2012 12:41 PM, Zabrane Mickael wrote:
> Hi Loïc,
> Compiling lastest Cowboy from github with R15B01 and running Dialyzer, I got this:
> cowboy $ make dialyze
> Checking whether the PLT .cowboy.plt is up-to-date... yes
> Proceeding with analysis...
> cowboy_http_protocol.erl:36: Callback info about the cowboy_protocol behaviour is not available
On Tue, Aug 14, 2012 at 1:41 PM, Zabrane Mickael <zabra...@gmail.com> wrote: > Hi Loïc,
> Compiling lastest Cowboy from github with R15B01 and running Dialyzer, I got this:
> cowboy $ make dialyze > Checking whether the PLT .cowboy.plt is up-to-date... yes > Proceeding with analysis... > cowboy_http_protocol.erl:36: Callback info about the cowboy_protocol behaviour is not available
I need to send stream via HTTP without end and without chunked response.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
