Do I have to force push from my local repo to my origin when rebasing from upstream during a pull-request?

Question

Given the following scenario:

1. I fork repo A [HEAD points to c0]
2. I commit locally [l0], push to origin and create PR
3. The upstream repo owner comments on my PR and asks me to rebase
4. I fetch from upstream/master (it's HEAD now points to c1) and rebase against it (so I have c0->c1->l0)
5. I commit locally [l1] the changes and try to push to origin

At this point my push is declined since my local and my origin have diverged and I find that I need to force push my local master to my origin in order for the PR to be correct (i.e. only contain l0 and l1).

My question is whether force-pushing is the common practice or am I making a mistake somewhere along the line? The way I understand it once I push to my origin and rebase locally from upstream the history diverges and force is required.

Update:
I've come to learn that I am doing a mistake and that is that I'm rebasing during the PR. a "forker" should merge from upstream and that will not rewrite his history on origin and so not cause any issues.
I've accepted the answer below as it is possible the question wasn't phrased clearly enough to reflect that I'm questioning the entire process inclusive of merge vs. rebase

Answer 1

In this case, force-pushing is OK. Git is preventing you from pushing normally as a safety mechanism to prevent you from accidentally overwriting your original branch. But in this case, you actually do want to overwrite it.

The only other case where a force-push would not necessarily be a good idea is if your branch was being shared with other people, who have copies of your old commits. Even in this case, a force-push is a feasible option, but it just means that everyone who has your old commits has to redo or rebase their work on top of your new commits, which can be difficult to coordinate, and a lot of extra work.