12 respuestas en este tema

[el-mono]

Buenas.

 

Necesito utilizar un servicio para envío de sms en mi software, para ello en una Unit coloque un método para enviar la url que previamente arme pero en el método Get me tira el error: http/ 1.1 bad request

 

Pero si pego la URL en el navegador la ejecuta y manda el mensaje correctamente.

delphi

function enviarSMS (url : string) : string;
var
  obtenerHTTP : TidHTTP;
  web : TStringList;
begin
  web := TStringList.Create;
  obtenerHTTP := TidHTTP.Create(nil);
  try
    web.Text := obtenerHTTP.Get(url);
  except
    on e: exception do
    begin
      obtenerHTTP.Free;
    end;
  end;
  enviarSMS := web.Text;
end;

Función que arma la url que luego paso a la función de arriba.

delphi

function TformEnvioSMS.componerURLFinal;
var
  url, numeroTelefono, mensaje, usuario, contrasena : string;
  urlFinal : string;
begin
  url := 'http://servicio.smsmasivos.com.ar/enviar_sms.asp?api=1';
  //txtURL.Text;
  numeroTelefono := txtNumeroMovil.Text;
  mensaje := txtMensaje.Text;
  usuario := 'Usuario1010';
  //txtUsuario.Text;
  contrasena := 'Password123';
  //txtPassword.Text;
 
  urlFinal := url + '&Usuario=' + usuario + '&Clave=' + contrasena + '?Tos=' + numeroTelefono +
      '&Texto=' + mensaje ;
 
  txtURLFinal.Text := urlFinal;
end;

[Delphius]

Yo te sugeriría que le pases los parámetros no por la URL sino mediante un TStrings. En este hilo mio al final expongo la forma de usar el método sobrecargado Get/Post que acepta parámetros. Y posiblemente lo mejor sería almacenar el contenido devuelto en un Stream y después convertirlo a string considerando el encode.

 

No estoy seguro, pero quizá el problema puede que sea cosa de ContentType.... podrías probar las sugerencias que se dan en este "hilo" en StackOverflow.

Y a lo mejor no estás usando la versión de la biblioteca SSL adecuada.

 

Las causas por un Bad Request pueden ser varias. Por cierto, ayuda mucho a saber que número de error te arrojó.

 

Saludos,

[enecumene]

Es que hay dos ? en el enlace, cambia ?tos= por &tos=

[el-mono]

Caramba, estaba tocando el código y me quedo ?Tos= pero lo tenia &Tos=

 

Las funciones que describo arriba las tome de un ejemplo de esta web http://www.ajpdsoft....iewtopic&t=1207

Lo raro del ejemplo es que ellos arman la URL desde unos Edit's y les funciona y envía los SMS pero si les asigno a las variables los valores por código pues ya no le gusta y me arroja:

 

Http/1.1 400 Bad Request

 

Delphius voy a probar con lo que me recomendaste.

[enecumene]

Veamos, ese error indica que el webservice que recibe lo que envías espera valores String y no XML, por favor, pega aquí el resultado de web.txt

[Delphius]

Veamos, ese error indica que el webservice que recibe lo que envías espera valores String y no XML, por favor, pega aquí el resultado de web.txt

 

¿Cómo determinas si lo que espera la URL es string o XML? El está armando la url con contenido string. En ningún momento de su código hace un XML.

 

Aunque tengo la sospecha de que si la excepción se produce en el método Get() es probable que no llegue a obtenerse la respuesta y por tanto el contenido de Web.Text sea vacío.

 

Saludos,

[enecumene]

Mmm, ahora que lei detenidamente el código, no debería ser post()?, ya que lo que haces es enviar un sms y no recibir un sms.

Delphius, siendo que trabaja a través de un webservice asumí que a través de la url se armaba un xml y luego se enviaba.

[Delphius]

Mmm, ahora que lei detenidamente el código, no debería ser post()?, ya que lo que haces es enviar un sms y no recibir un sms.

Delphius, siendo que trabaja a través de un webservice asumí que a través de la url se armaba un xml y luego se enviaba.

 

No necesariamente, aunque yo también lo he pensado al comienzo... Algunas operaciones pueden hacerse indistintamente con GET y POST.

La posible ventaja de hacerlo directamente con GET es que te evitas el doble envío de petición POST->GET. Es decir con GET le pides los resultados de una sola vez, en cambio con POST envias y luego le sigue un GET.

 

Yo no se si es que detrás de esa URL hay un WebService, o si se trata de una simple página en ASP. No soy experto en ese tema. Se que los WebServices trabajan con XML (y que creo, algunos, que también pueden interactuar con JSON) pero al menos por lo que nos ha comentado el-mono no puedo asegurarlo.

Si a pesar del error logra capturar alguna respuesta web en ese Memo, nos puede ayudar a ver el problema.

 

En lo que estoy pensando es que posiblemente los nombres de los parámetros, o el orden no estén bien. Pero si el-mono dice que copiando la URL que arma le funciona... es algo raro. Y eso a mi, y viendo el error, me hace pensar que el problema posiblemente esté en el ContentType del Request, como se sugiere en la pregunta de StackOverflow que puse en el enlace en un mensaje anterior. Pero más raro me resulta debido a que el procedimiento de funcionamiento del servicio que describe la empresa que lo ofrece sugiere algunas cosas un tanto diferentes...

 

¿No será que el contenido del request está en XML y no en "HTML puro"? Nos hace falta más info sobre cómo es que funciona ese servicio de envio masivos de sms que pretende usar. Para lograr hacerle un poco de "ingeniería inversa" necesitamos entrar y para ello hay que registrarse y hacer pruebas... y eso implica gastar dinero.

 

Lo peor que puede hacer el-mono es copiar y pegar tan libremente el código de otro sitio, y que cuya solución fue pensada para un servicio de otro emprendimiento sin haber analizado de forma objetiva y precisa como es que funciona el servicio que quiere usar.

¿Porqué digo esto último? Porque he estado visitando la página de la empresa que da el servicio y por lo que estoy entiendo se trata de una plataforma web con un proceso por 4 partes: 1) Ingresas, 2) escribes el mensaje 3) seleccionas los contactos y 4) por último lo envías.

 

el-mono nos vas a tener dar más info porque así viendo el error y ese código imposible será llegar a una solución. Cuéntanos más... ¿De donde sale ese primer parámetro api=1? ¿Son efectivamente esos los parámetros y en el orden correcto? ¿Es lo que ves cuando entras manualmente al sitio?

 

Hay demasiadas preguntas.

 

Saludos,

[el-mono]

Perdón por la demora.

 

La empresa que utilizo se llama SMSmsivos y tienen una guia para utilizar sus servicios de donde saque como se arma la URL con sus parámetros, al parecer (no hable con el representante aun) es simplemente una pagina en ASP no un Webservices.

 

Para decirle que estas mandando texto plano se coloca en la URL API=1, la verdad el código que pegue aquí lo saque de la Web porque no sabia como hacer. Aqui pego lo que dice el PDF que te mandan para que programes el servicio:

 

 

Envío de mensajes vía http (en tiempo real)

La aplicación que desee enviar mensajes SMS a través de SMS Masivos deberá hacer un

llamado HTTP con método GET o POST a la siguiente dirección:

http://servicio.smsm...r_sms.asp?api=1

Los parámetros son:

USUARIO: Nombre de usuario que le otorgó SMS Masivos (obligatorio)

CLAVE: Contraseña del usuario que le otorgó SMS Masivos (obligatorio)

TOS: Número de teléfono móvil al que se le desea enviar el mensaje (sin código de país,

con código de área) (obligatorio)

Nota para Argentina: los números van sin el CERO y sin el 15. 10 dígitos en total.

Nota para Guatemala: 8 dígitos en total.

Nota para México: 10 dígitos en total.

Nota para Perú: 9 dígitos en total.

Nota para Uruguay: 8 dígitos en total. No hace falta el cero inicial. Si se coloca, el sistema

lo quita automáticamente.

TEXTO: Mensaje que se desea enviar (máximo 160 caracteres) (obligatorio).

Los caracteres permitidos son:

Página 1 de 11

Dirección para consultas y dudas: soporte@smsmasivos.com.ar

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!?#$%()*

+, -./:;=@ y el espacio

API: Variable fija de valor 1 para indicar que las respuestas regresarán como texto plano

(obligatorio)

TEST: Indica si se desea que se validen los datos del mensaje pero que no se envíe

(opcional, debe colocarse un “1”)

IDINTERNO: Es un indicador interno de su sistema. Al recibir las respuestas a sus

mensajes enviados, opcionalmente, podemos enviar este ID interno. Es un campo

alfanumérico de, como máximo, 50 caracteres (opcional)

FECHADESDE: Permite programar la fecha y hora en que será enviado el mensaje. La

fecha y hora deben estar en formato ISO y correspondientes al huso horario GMT -3.

Ejemplo: 2014-06-16 17:56:00 . En caso de no agregar este parámetro, o que el formato

sea incorrecto, el envío será realizado inmediatamente. (opcional)

RESPUESTANUMERICA: Indica si se desea que las respuestas de la API contengan un

código numérico que identifique el resultado del envío (opcional, debe colocarse un “1”)

 

Ejemplo de llamado:

 

http://servicio.smsm...EMO500&clave=DE

MO500&tos=1144445555&texto=Mensaje

[Delphius]

Ummm. Si es como lo dice el PDF, debería funcionarte sin problemas.

En teoría es indistinto si se emplea mayúsculas o minúsculas al nombrar los parámetros, pero sugiero respetar tal como fueron nombrados. Si la doc dice mayúsculas, respétalo.

 

Me inclino a pensar que el problema posiblemente esté en una mal formación de la URL al momento de pasar el mensaje. Deberías tener una rutina de "escape". Posiblemente se deba a que algún carácter que contiene el mensaje no es válido. El que funcione si pones la URL en el navegador me hace pensar que el navegador reemplaza los carácteres no permitidos por su "representación URL" mientras que el componente TIdHTTP no es capaz de hacerlo. Por ejemplo la ñ no es permitida... Y también debe cuidarse cuando uses ?, & y/o = en el texto ya que esto puede dar a confusión y el servidor web detectaría que se estaría intentando pasar nuevos parámetros.

 

Por ejemplo, que pasaría si el texto del mensaje tendría esto: ?Donde te busco. Me &da= donde sea

 

Recibirás un error por que hay un nuevo ? que indica que se están pasando parámetros. Luego intentará interpretar a da como un parámetros cuyo valor es "donde sea".

Me pregunto si no será que al texto lo deberías entrecomillar, con las simples al menos.

 

Saludos,

[Agustin Ortu]

Yo tuve problemas con Indy para consumir web services. Podrías probar con synapse que funciona de maravilla

[Delphius]

Este caso no se trata de WebServices. Es una página ASP.

La curiosidad que me queda es ¿y que respuesta devuelve el servidor web cuando se envía algo exitosamente?

Saludos

[Agustin Ortu]

Lo de que fuera web service es medio anecdótico. Yo haría una prueba con synapse. Indy siempre me pareció muy complejo, posiblemente el problema este en que falte cambiar una propiedad o enlazar con alguno de los otros componentes extra

Además, no todos los web services trabajan si o si con JSON o XML como comentan más arriba. Hoy por hoy es como las de facto, pero no es requisito. Hay muchos servicios que te permiten hacer solicitudes sencillas sin ningún formato raro (básicamente en la URL específicas todo). El que ahora las respuestas sean JSON o XML es porque todo el mundo debe estar usando frameworks que trabajan de esa manera y funcionan bien

Por otro lado es algo muy bueno, todavía hay dando vueltas los archivos delimitados por caracter "X" y con un formato que sino tenés el manual son indescifrables

Editado por Agustin Ortu, 12 febrero 2017 - 11:25 .