If your authentication protocol is about sending a password to the server, or a hash of the password, with plain HTTP, then this is inherently very weak, for two reasons:
Someone spying on the line could record what the client sends. If just sending these bytes grants access, then the attacker could simply send them again. That's a replay attack. This issue is what @AviD alludes to in his answer. No amount of hashing will fix that. Some protocols try to correct this issue by including a "challenge" from the server (a random value, created anew for each connection), to be hashed together with the password on the client; that's what HTTP Digest authentication is about.
Even if the authentication worked, this is still plain HTTP, so whatever data will be sent afterwards will be vulnerable to eavesdropping and alterations by attackers. If the transport medium is unprotected, then the authentication will deter only the most unsophisticated of attackers. This is where HTTP Digest fails.
Therefore, you really need SSL (aka HTTPS), not only to convey the password or hash thereof, but also the remainder of the conversation between client and server.
I hereafter assume that the protocol is run within an SSL tunnel. You are right to want to use a slow hash function like bcrypt or PBKDF2; note that a salt is also needed to prevent cost sharing (e.g. precomputed tables). Slow, salted hashing is used to cope with the intrinsic weakness of passwords. Now, you might want to offload some of the hashing effort on the client. This may work, but it raises some practical issues:
Since the password processing must include a salt, a new one for each password instance, then the salt must be conveyed to the client, so that the client may include the salt in the hashing it performs. This increases the protocol complexity: the client must first send the user name to the server, then the server must send back the salt, and (only then) can the client begin to hash the password. This is one more network roundtrip than with the usual "send user name and password as one POST request".
Therefore usual wisdom is that performing part of the password hashing on the client is not worth the effort.