Código de estado HTTP 400 en los países de Medio Oriente

Question

Tengo una aplicación para iPad que carga una Plist desde una multa de servidor en una vista UIWebView, pero cuando intento obtenerlo como cadena de respuesta del servidor, devuelve un código de estado HTTP 400 con una cadena de respuesta como error de solicitud (inválido_request).

Sucede solo en los países de Medio Oriente. Un usuario de los Emiratos Árabes Unidos confirmó el problema al que envié una compilación ADHOC para las pruebas. La aplicación devuelve un código de estado de 400, pero la Plist se carga bien en UIWebView.

Había estado intentando 2 servidores diferentes: AWS Server y otro alojado en EE. UU. Para ambos servidores, proporciona el mismo código de estado.

¿Alguien puede dar sugerencias sobre por qué debería suceder?

Aquí hay una parte del código:

  .....
    ASIHTTPRequest *request = [[[ASIHTTPRequest alloc] initWithURL:url] autorelease];
    [request addRequestHeader:@"Content-Type" value:@"text/xml; charset=utf-8"];
    [request addRequestHeader:@"Accept-Encoding" value:@"text/xml;charset=utf-8"];

    [request setRequestMethod:@"GET"];
    [request setDelegate:self];

    [request setDidFinishSelector: @selector(gotTheResponse:)];

    [request setDidFailSelector: @selector(requestFailed:)];
    [networkQueue addOperation: request];
    [networkQueue go];
....

Answer 1

No estoy seguro de si este es el problema o no, pero esta línea:

[request addRequestHeader:@"Accept-Encoding" value:@"text/xml;charset=utf-8"];

Creo que está estableciendo un valor no válido para el encabezado de codificación de aceptación. Los valores más habituales serían "Compress, GZIP", y realmente no debería necesitar establecerlo usted mismo. Si desea que el servidor devuelva el mensaje de texto/XML, eso debe entrar en un encabezado de "aceptar", aunque es posible que no lo necesite en absoluto dependiendo de la configuración del servidor.

También es inusual usar un encabezado de tipo de contenido en una solicitud GET, ¿hay alguna razón por la que está agregando eso?

Una posibilidad final sería si la URL contenga caracteres inusuales, potencialmente eso podría hacer que cualquier servidor proxy devuelva un error.