Jeff King <> 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

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
More majordomo info at

Reply via email to