I've been intending to respond to these messages, but haven't had the chance yet. I'm glad you picked it up.
> You send here solution, right? Yes, I wanted to make it easier for you (at least finding the problem if not fixing it), but like most library users, I wouldn't have wanted to alter the source without your blessing. Even if they could see that it works, there are good reasons not to implement it: they don't know me (much, yet); another developer's review of the _quick_ code change would be good; *your* review of the proposed change would be much better; and even if the code change was good (for their case, or whatever), if you disagreed with it, and it wouldn't be in the next release of Synapse, most of us wouldn't want to "fork" the code at the library level. We didn't know till you responded what would happen with the proposed solution. There might well have been a better one... > Yes, this is right fix. Better words are 'workaround', because server > sending unlogical combination of headers.If server knows length of > content, then why using chunked transfer? > > In RFC-2616 is written: ... Yes, very true, but now Synapse is even more compliant ;-) with The Internet Robustness Principle: "Be liberal in what you accept, and conservative in what you send." (Attributed to Jon Postel--Postel's Law) As seen in these, and more RFCs ;-) (all RFC quotes to end of this message now): ---------------------------------------------------------------------------- --------- ********** RFC 760 "DOD STANDARD INTERNET PROTOCOL" 3.2. Discussion The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). ********** RFC 761 "DOD STANDARD TRANSMISSION CONTROL PROTOCOL" 2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. ********** RFC 791 "Internet Protocol" (and 793) 3.2 Discussion The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). ********** RFC 1122 "Requirements for Internet Hosts -- Communication Layers" 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: "Be liberal in what you accept, and conservative in what you send" Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course! Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines fourpossible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure. The second part of the principle is almost as important: software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is "watch out for misbehaving hosts"; host software should be prepared, not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
