✏ Fix incorrect Celery URLs in docs (#2100)

docs/en/docs/tutorial/background-tasks.md

@@ -81,7 +81,7 @@ You can see more details in <a href="https://www.starlette.io/background/" class
 
 ## Caveat
 
-If you need to perform heavy background computation and you don't necessarily need it to be run by the same process (for example, you don't need to share memory, variables, etc), you might benefit from using other bigger tools like <a href="http://www.celeryproject.org/" class="external-link" target="_blank">Celery</a>.
+If you need to perform heavy background computation and you don't necessarily need it to be run by the same process (for example, you don't need to share memory, variables, etc), you might benefit from using other bigger tools like <a href="https://docs.celeryproject.org/" class="external-link" target="_blank">Celery</a>.
 
 They tend to require more complex configurations, a message/job queue manager, like RabbitMQ or Redis, but they allow you to run background tasks in multiple processes, and especially, in multiple servers.
 

docs/en/docs/tutorial/sql-databases.md

@@ -235,7 +235,7 @@ Now let's check the file `sql_app/schemas.py`.
     To avoid confusion between the SQLAlchemy *models* and the Pydantic *models*, we will have the file `models.py` with the SQLAlchemy models, and the file `schemas.py` with the Pydantic models.
 
     These Pydantic models define more or less a "schema" (a valid data shape).
-    
+
     So this will help us avoiding confusion while using both.
 
 ### Create initial Pydantic *models* / schemas
@@ -470,7 +470,7 @@ Our dependency will create a new SQLAlchemy `SessionLocal` that will be used in
     We put the creation of the `SessionLocal()` and handling of the requests in a `try` block.
 
     And then we close it in the `finally` block.
-    
+
     This way we make sure the database session is always closed after the request. Even if there was an exception while processing the request.
 
     But you can't raise another exception from the exit code (after `yield`). See more in [Dependencies with `yield` and `HTTPException`](./dependencies/dependencies-with-yield.md#dependencies-with-yield-and-httpexception){.internal-link target=_blank}
@@ -553,7 +553,7 @@ And as the code related to SQLAlchemy and the SQLAlchemy models lives in separat
 
 The same way, you would be able to use the same SQLAlchemy models and utilities in other parts of your code that are not related to **FastAPI**.
 
-For example, in a background task worker with <a href="http://www.celeryproject.org/" class="external-link" target="_blank">Celery</a>, <a href="https://python-rq.org/" class="external-link" target="_blank">RQ</a>, or <a href="https://arq-docs.helpmanual.io/" class="external-link" target="_blank">ARQ</a>.
+For example, in a background task worker with <a href="https://docs.celeryproject.org/" class="external-link" target="_blank">Celery</a>, <a href="https://python-rq.org/" class="external-link" target="_blank">RQ</a>, or <a href="https://arq-docs.helpmanual.io/" class="external-link" target="_blank">ARQ</a>.
 
 ## Review all the files
 
@@ -648,7 +648,7 @@ The middleware we'll add (just a function) will create a new SQLAlchemy `Session
     We put the creation of the `SessionLocal()` and handling of the requests in a `try` block.
 
     And then we close it in the `finally` block.
-    
+
     This way we make sure the database session is always closed after the request. Even if there was an exception while processing the request.
 
 ### About `request.state`