Jeff King <peff@xxxxxxxx> writes: > That being said, git _could_ be more liberal in accepting a content-type > with parameters (even though it does not know about any parameters, and > charset here is completely meaningless). I have mixed feelings on that. It may be just a matter of replacing strbuf_cmp() with "the initial part must be this string" followed by "it could have an optional whitespaces and semicolon after that", but I share the mixed feelings. I am not sure if it is a right thing to follow "be liberal to accept" dictum in this case. It may be liberal in accepting blindly, but if the other end is asking a behaviour that is not standard (but perhaps in future versions of Git such an enhanced service may be implemented by the client), by ignoring the parameter we do not even know about how to handle, we would be giving surprises to the overall protocol exchange. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html