fix: fetch_url: return err on non 2xx reponses

The main reason for this change is the app picker
that Delta Chat clients use, which utilizes
the `fetch_url` function.
Sometimes we get an error from the server,
but we have no way to figure out that it's an error,
other than inspecting the body, which we don't (and shouldn't) do.
This results in us attempting to send webxdc apps
that are not even valid .zip files.

Another, arguably even worse thing is that
we also put the error responses to the cache,
so it's not easy to recover from such an error.

So, let's just return an error if the response code
is not a successful response code.

Author: WofWca

deltachat-jsonrpc/src/api/types/message.rs

@@ -143,6 +143,7 @@ impl MessageObject {
         let override_sender_name = message.get_override_sender_name();
 
         let webxdc_info = if message.get_viewtype() == Viewtype::Webxdc {
+            // WebxdcMessageInfo::get_for_message(context, msg_id).await.ok()
             Some(WebxdcMessageInfo::get_for_message(context, msg_id).await?)
         } else {
             None

src/chat.rs

@@ -925,6 +925,24 @@ impl ChatId {
             }
             _ => {
                 if msg.viewtype == Viewtype::File {
+                    // So, it's this guy? Do we have to validate the zip file?
+                    // But it's a little bruh, because it's sort of expensive.
+                    // We also can't avoid going from File to Webxdc
+                    // because we have a file picker to attach webxdc apps.
+                    //
+                    // Do we just handle the "invalid xdc"
+                    // when fetching / sending the draft / draft message?
+                    // How do we handle it though?
+                    // Do we keep Viewtype as Webxdc,
+                    // but return no `webxdcInfo`?
+                    // Well, if you think about it, it is possible to send
+                    // other `Viewtype` (e.g. video) even if the file
+                    // isn't a valid video file.
+                    // So, maybe we should do the same?
+                    // Just return `null` for `webxdc_info`.
+                    //
+                    // TODO also perhaps we need to document that when we use
+                    // Webxdc viewtype, it MUST be a valid file.
                     if let Some((better_type, _)) = message::guess_msgtype_from_suffix(msg)
                         // We do not do an automatic conversion to other viewtypes here so that
                         // users can send images as "files" to preserve the original quality
@@ -2783,6 +2801,7 @@ async fn prepare_msg_blob(context: &Context, msg: &mut Message) -> Result<()> {
                 }
             }
         } else if msg.viewtype == Viewtype::Webxdc {
+            // Yeah, so the error occurs here when we do
             context
                 .ensure_sendable_webxdc_file(&blob.to_abs_path())
                 .await?;

src/net/http.rs

@@ -261,6 +261,18 @@ async fn fetch_url(context: &Context, original_url: &str) -> Result<Response> {
             continue;
         }
 
+        if !response.status().is_success() {
+            return Err(anyhow!(
+                "The server returned a non-successful response code: {}{}",
+                response.status().as_u16(),
+                response
+                    .status()
+                    .canonical_reason()
+                    .map(|s| format!(" {s}"))
+                    .unwrap_or("".to_string())
+            ));
+        }
+
         let content_type = response
             .headers()
             .get("content-type")

src/webxdc.rs

@@ -237,6 +237,7 @@ const STATUS_UPDATE_SIZE_MAX: usize = 100 << 10;
 
 impl Context {
     /// check if a file is an acceptable webxdc for sending or receiving.
+    // Wait, isn't this duplicated `ensure_sendable_webxdc_file`?
     pub(crate) async fn is_webxdc_file(&self, filename: &str, file: &[u8]) -> Result<bool> {
         if !filename.ends_with(WEBXDC_SUFFIX) {
             return Ok(false);